Improving project DX and workflow | interactions.py | Page 1

grim sluice Mar 30, 2024, 8:25 AM

#

Hi all, I'd like to look into ways we could improve our developer experience with working on the library. Currently, we are using old but modified configs, and we've been adding stuff on top of the project over time to suit our needs, although leading to some things either being outdated or in need of improvement. (Old issue template links, unnecessary pre-commit configuration fields, lack of README details, lack of more example scripts, list goes on)

I'd like to ideally run some polls in #polls to further gage interest, but I think spinning up a post here is smarter instead to aggregate some feedback on what we could do to make things better. This project is not in any dire need of a rewrite or overhaul, but we could certainly make the development experience better for all of us to continue adopting newer tools that suit our needs more towards an automation path.

My primary interest is to do more CI/CD work in the background for things like bridging documentation with discord_typings, upgrading our testing suite, and doing more documentation to cater towards making other developers wishing to contribute on our project have an easier time doing so.

polar stump Mar 30, 2024, 1:34 PM

#

id actually like to make our testing suite so that it doesnt try to run like 8 tests at once

#

i understand the need to test every combination of extra deps but i dont think all of them need to use the testing bot to test everything - just test the bot-specific stuff with .[all]

#

our ci is failing because of it

#

also can we please use https://pre-commit.com/#overriding-language-version to force a 3.11/3.12 language version 😅

polar stump Mar 30, 2024, 4:16 PM

#

one last thing: polls made a neat script called blackdwarf that converts star imports to expanded out imports. id like to fork it and add it to our pre-commit so that it instead automatically fills in imports for the __init__.pys based on each files __all__s, because doing that as a human sucks

GitHub

GitHub - LordOfPolls/BlackDwarf: A Python script that eliminates wi...

A Python script that eliminates wildcard imports. Contribute to LordOfPolls/BlackDwarf development by creating an account on GitHub.

grim sluice Mar 30, 2024, 9:16 PM

#

noting everything – @polar stump i'm happy to give you passover on the testing suite, if you can make it work, i'm not going to refrain from allowing you that

#

i'll be pushing all documentation-related changes covering the repository as a whole in the refresh branch, but prs can also be made to that branch for things like ci/cd, testing and etc. if need be to eventually make it a larger scope pr

grim sluice Mar 30, 2024, 9:36 PM

#

polar stump one last thing: polls made a neat script called [blackdwarf](https://github.com/...

and yeah i think we could certainly do this but we'll need maintainer coverage if that's going to be the case, reckoning we'd then be introducing a custom script for dev needs and we'll need the ability to update whenever need be

#

i'd also rather not call it blackdwarf pepeW

polar stump Mar 30, 2024, 9:36 PM

#

pfft hence why i suggest a fork

#

(or we could ask polls for it, he'd probably do that)

grim sluice Mar 30, 2024, 9:36 PM

#

i think plucksort or psort would be nicer since we're doing more of like.. an "extraction" of the star import ig?

grim sluice Mar 30, 2024, 10:36 PM

#

@polar stump what's the pypi name we're trying to get everyone to use? interactions-py?

polar stump Mar 30, 2024, 10:36 PM

#

i dont even know anymore

#

but thats my preferred one, though we should maintain the old one too until like v6

grim sluice Mar 30, 2024, 11:13 PM

#

alright, readme has been cleaned up, have fun eye googlin it

polar stump Mar 30, 2024, 11:34 PM

#

Although not recommended, we additionally support usage alongside other libraries.*
im going to politely ask for this section to be removed entirely

#

if it isnt recommended, we shouldnt be stating it on our readme

grim sluice Mar 30, 2024, 11:34 PM

#

i'm gonna take it we want to avoid help hell from it too..

polar stump Mar 30, 2024, 11:34 PM

#

yes

grim sluice Mar 30, 2024, 11:35 PM

#

fair enough, it's a superficial note anyhow, the asterisk was deliberate to show that too

polar stump Mar 30, 2024, 11:35 PM

#

im otherwise digging the refresh

#

a few nitpicks i have with it but you know

grim sluice Mar 30, 2024, 11:42 PM

#

i'll make sure to put them on my calendar for "should care soon"

#

i'll use this post to aggregate that feedback as things continue to change

#

speaking of - holy crap our contributing guidelines and reqs are very outdated

polar stump Mar 30, 2024, 11:43 PM

#

fukt

grim sluice Mar 30, 2024, 11:43 PM

#

like holy shit

polar stump Mar 30, 2024, 11:43 PM

#

yeah...

grim sluice Mar 30, 2024, 11:43 PM

#

we're still using rST for it too???

#

deadInside

#

@zinc bronze i'm dragging you in here now

#

yeah there's no way i wasn't high when i wrote this, that or my english really did suck back then

#

half of the shit i wrote makes no sense

#

jotting some ideas down:

steer away from the "stable"/"unstable" branch naming - move back to dev, consider "release" or main for stable
use our own conventional commit guidelines - extend current conv comm., add new ones, e.g. "meta," "github," etc.
highlight how we use semver, give brief example of usage depending on our dev changes
debate between using wiki or keeping separate markdown files (if the latter, my proposal is placing readme's within folders of the project arch)

#

i'll give full discretion to sila so i'm not stepping on toes here, if something wants/needs to be changed, alert me please

zinc bronze Mar 30, 2024, 11:49 PM

#

Good morning

#

Reading everything from overnight now 🙂

grim sluice Mar 30, 2024, 11:51 PM

#

glhf, and just to put it out here now so we're all on the same page - this branch can be stopped at any time. if we're not satisfied with changes, or don't want them, we have the ability to do that since we're not reactively updating our other 2 main branches

polar stump Mar 30, 2024, 11:51 PM

#

i will say i prefer the latter option for bullet point 4

#

being tied to githubs wiki does not sound fun

zinc bronze Mar 30, 2024, 11:51 PM

#

grim sluice <@229350299909881876> what's the pypi name we're trying to get everyone to use? ...

Yeah, this is definitely the one we want to be using

grim sluice Mar 30, 2024, 11:51 PM

#

i think the other problem with wiki as well is anyone can edit it yea?

zinc bronze Mar 30, 2024, 11:51 PM

#

You can configure that

grim sluice Mar 30, 2024, 11:51 PM

#

unless they finally changed that, it used to be that

#

oh neato

polar stump Mar 30, 2024, 11:53 PM

#

in terms of conventional commits - i think we've so rarely deviated from it that im not sure if extending it is needed

zinc bronze Mar 30, 2024, 11:54 PM

#

I'm happy to extend if we need to, but yeah, I can't really think of a reason to off the top of my head

grim sluice Mar 30, 2024, 11:55 PM

#

how do we feel about all of these editor config files in our root?

#

any we wish to .gitkeep or .gitignore?

#

~~(i'm looking at yours sila)~~

#

what about the confliction between poetry and setup.py? I believe we could actually rewrite one of our workflows to just run through poetry build and upload instead

zinc bronze Mar 30, 2024, 11:57 PM

#

Are you talking about .editorconfig? Because we definitely need to keep that

#

~~I can't see any actual editor specific files in the repo~~ I'm happy to kill the interactions.py.code-workspace though

grim sluice Mar 30, 2024, 11:58 PM

#

.code-workspace, .egg-info

#

well i'm honestly straight up guessing the 2nd one is that

zinc bronze Mar 30, 2024, 11:59 PM

#

.egg-info is a build artifact that never should have been committed, I think?

grim sluice Mar 30, 2024, 11:59 PM

#

oh our ignore file already tracks it, disregard

zinc bronze Mar 30, 2024, 11:59 PM

#

But yeah, .editorconfig is a standardized file that clobbers people's IDEs into doing the right thing in terms of indentation, tabs-v-spaces, etc

#

All popular IDEs support it, and it reduces unnecessary whitespace changes across contributors

polar stump Mar 31, 2024, 12:01 AM

#

my testing setup ironically means i never use it fukt

grim sluice Mar 31, 2024, 12:01 AM

#

holy fuck what a blast from the past

polar stump Mar 31, 2024, 12:01 AM

#

but i see its use

zinc bronze Mar 31, 2024, 12:01 AM

#

It basically says "While working on i.py, ignore the user's personal preferences, and use mine instead"

grim sluice Mar 31, 2024, 12:01 AM

#

do yall wanna keep these for nostalgia sake or are we cool with yeeting them

zinc bronze Mar 31, 2024, 12:01 AM

#

kill it with fire

polar stump Mar 31, 2024, 12:02 AM

#

got it, force pushing to stable /j

zinc bronze Mar 31, 2024, 12:02 AM

#

😄

grim sluice Mar 31, 2024, 12:04 AM

#

for contrib reqs, are we alright with maintainers/org members (us) creating separate branches while outsiders need to do forks, or should we all do forks?

polar stump Mar 31, 2024, 12:05 AM

#

i think the former is sane enough

zinc bronze Mar 31, 2024, 12:05 AM

#

I always do a combination of both, tbh

polar stump Mar 31, 2024, 12:05 AM

#

same

zinc bronze Mar 31, 2024, 12:06 AM

#

Branches are good for visibilty, so people can see what we're working on (especiall with #github) and potentially test. But the super rough stuff starts in my fork.

polar stump Mar 31, 2024, 12:06 AM

#

i dont want to flood #github when my brain decides today is the day to make 15 prs

zinc bronze Mar 31, 2024, 12:06 AM

#

😄

#

So yeah, leave that one to user-discretion.

grim sluice Mar 31, 2024, 12:09 AM

#

do we still want requirements-x.txt?

zinc bronze Mar 31, 2024, 12:10 AM

#

I mean, it's the one that actually matters. The poetry file is actually the redundant one

#

Well, requirements.txt is. The other two aren't used, I guess

grim sluice Mar 31, 2024, 12:14 AM

#

our only reference on those other req files, including dev, is used in contributing.rst

#

only mentioned for installation purposes

polar stump Mar 31, 2024, 12:16 AM

#

which has been wrong for ages

#

we rely on pip install .[dev] these days

#

or docs i forget

zinc bronze Mar 31, 2024, 12:17 AM

#

docs and tests

#

So yeah, kill those two files

#

steer away from the "stable"/"unstable" branch naming - move back to dev, consider "release" or main for stable
Is there a particular reason to do this? It'll break scripts, both internally and downstream, and doesn't really have any benefit.

#

I remember the fallout from the master -> main changeover, and that at least had a good reason behind it

grim sluice Mar 31, 2024, 12:18 AM

#

naming is the only thing that comes to mind, i also agree that it wouldn't have any benefit, but that's the only thing it would

#

oh that was a stupid debate in the github community

#

i feel like this may be a debated one, but how do we feel about running mypy validation within pre-commit?

zinc bronze Mar 31, 2024, 12:20 AM

#

I want to, but it's still failing

grim sluice Mar 31, 2024, 12:20 AM

#

it'll have to include a mypy config if we do it because i know plenty of us have our own stances about what should and shouldn't be allowed

#

yeah i want to as well, i want to find a way to make it work for us, it's going to make enforcing typings a whole lot nicer in the long run

zinc bronze Mar 31, 2024, 12:21 AM

#

Absolutely

grim sluice Mar 31, 2024, 12:21 AM

#

didn't we used to have a mypy config file somewhere actually? where is it?

#

smth smth mypy.ini

zinc bronze Mar 31, 2024, 12:22 AM

#

It's included within pyproject

#

Right now it's very barebones though:

[tool.mypy]
ignore_missing_imports = true

zinc bronze Mar 31, 2024, 12:24 AM

#

grim sluice didn't we used to have a mypy config file somewhere actually? where is it?

A while back I cleaned up the root by moving everything that could go into pyproject from their own files to that one.

grim sluice Mar 31, 2024, 12:25 AM

#

i'm open to us modifying our mypy config but idk what would be our focus

zinc bronze Mar 31, 2024, 12:25 AM

#

I have a few rules I like having on

grim sluice Mar 31, 2024, 12:25 AM

#

i have one of my own i use that generally gets the job done nicely, it has my own caveats

#

feel free to share it here

zinc bronze Mar 31, 2024, 12:28 AM

#

I run with

show_error_codes = True
show_column_numbers = True
ignore_missing_imports = True
strict_equality = True
disallow_untyped_calls = True
warn_redundant_casts = True
disallow_incomplete_defs = True
check_untyped_defs = True
disallow_untyped_defs = True

But that might be too much too quickly. The big ones I'd want to use are disallow_incomplete_defs, disallow_untyped_defs, and strict_equality

grim sluice Mar 31, 2024, 12:31 AM

#

threw those in for now

grim sluice Apr 16, 2024, 2:01 PM

#

this is the current config i'm using and it's done wonders for me so far, although i have a fair amount of assert lines thrown about to make working with none types easier

#

[mypy]
; type accessibility & referencing
ignore_missing_imports = True
warn_redundant_casts = True
warn_unused_ignores = True
warn_incomplete_stub = True

; declaration partiality
disallow_incomplete_defs = True
disallow_untyped_defs = True

; type operation logic
strict_equality = True

; error message formatting
show_error_context = True
show_column_numbers = True
pretty = True
color_output = True
show_traceback = True

; avoids "typing.Any" hell entirely
disallow_any_explicit = True
disallow_subclassing_any = True

; suppresses type errors we know aren't necessary
disable_error_code = valid-type

; convenient warnings for code control flow and usage
warn_unused_imports = True
warn_unreachable = True

; guarantees type safety on declarations
check_untyped_defs = True

; assumes NoneType is of Optional[T]
strict_optional = False
implicit_optional = True

#Improving project DX and workflow