Suggestions for minor enhancements

[jharrisonSV]

Awesome stuff! I have a few suggestions for some potential enhancements that I've spotted whilst using omnidep:

• Allow specifying test files using a pattern e.g. local-test-pattern = "*test.py". A common, alternative approach to placing all your test files within a tests/ directory is to have them sit within your package itself, alongside the corresponding code that it is testing. Currently if you wish to structure my tests in this way you must list them all individually in local-test-paths, which quickly gets tedious for large projects. This doesn't have to be a new config option necessarily, perhaps just expanding the strings that local-test-paths can handle.
• An option to auto-sort dependencies in the pyproject.toml e.g. omnidep pyproject.toml --sort
• A pre-commit hook so that omnidep can be run automatically before every commit.

I'd be more than happy to contribute any of these if you deem them useful/valuable.

[sjjessop]

• Patterns: yes. I'll have a think about whether I prefer a new option or wildcards in the existing option.
• auto-sort: maybe but I think it's hard. The reason I didn't do anything about it to begin with is that builtin Python tomllib (and tomli) support reading only, not writing. There's a corresponding package tomli-w, but it's write-only. Re-writing a toml file while preserving comments and formatting isn't completely trivial, although maybe tomlkit? Re-ordering a list of things that might have comments on lines preceding the thing they refer to is also not completely trivial: what do we do with comment lines in the middle of the list of dependencies? I suppose we could just tell people not to do that if they set the auto-sort option. Or maybe we can strictly assume that any comment refers precisely to one line immediately following it, and move the comment with that line: then if this assumption is incorrect that's the user's fault, not ours ;-)
• pre-commit I've never understood or really looked at. I'm very old-fashioned and always assumed that it's up to the user (or the creator of the repo that uses omnidep) to put whatever commands they want into git pre-commit hooks (https://git-scm.com/docs/githooks). Does pre-commit deal automatically with the fact that different people will want to run omnidep in different ways, depending on their environment? omnidep pyproject.toml, poetry run omnidep pyproject.toml, or whatever? Of course I say this as a heretic who can't even necessarily use git pre-commit hooks at all, since I'm not necessarily running git from an environment that's capable of accessing the project's Python environment (cygwin vs Windows vs WSL).

[sjjessop]

I should add on the commit hooks: currently we can assume the user is using poetry, so poetry run should always work. But that's just because it's the only kind of data we can read from pyproject.toml. I've tried to leave a route to support other packaging tools in future, though: there's a fuction read_poetry that's called unconditionally from main.py, but that could be replaced with a factory that works out what tool you're using from the contents of pyproject and/or the command line. For projects not using poetry, I could add a feature to read the same project data from setup.py, or a requirements.txt file and a dev-requirements.txt file, or whatever. auto-sort would also have to take account of what kind of input file is used.

[jharrisonSV]

On auto-sort I was imagining that you could tell people that it will only sort successfully (or as expected) if they are consistent in their use of comments i.e. all comments refer to the line immediately following or all comments appear on the same line as the dependency. That feels like a pretty fair requirement and also encourages people to take up better commenting habits, which is never a bad thing :).

I have found a Poetry plugin for sorting dependencies https://github.com/andrei-shabanski/poetry-plugin-sort. I haven't tried using it but a brief scan shows it uses tomlkit so maybe that's the way to go. You could even tell people to use that plugin and let that do all the hard work!

[jharrisonSV]

After a very quick play around with the plugin I can confirm it does seem to move comments with success.

[sjjessop]

@jharrisonSV: you don't need support for Python 3.7, do you? I'm adding the wildcard feature, but I've also just removed Python 3.7 support so as to use the latest poetry. If you need it, I could do a release that lets you install it on Python 3.7, even though I'm no longer testing it there.

[sjjessop]

@jharrisonSV The two changes didn't conflict, so I flipped the order. v0.3.7 of omnidep has the wildcard feature, and v0.3.8 removes support for Python 3.7.

This ticket is now two parts done and one left to do:

• [x] local-test-paths can now contain wildcards. Based on your example, you probably want my/path/**/*test.py. One thing that might be useful, but that I haven't supported, is my/path/**/tests/*.py. It would be a bit fiddlier because I'd have to work out how much of the path is supposed to be globbed -- probably from the first component that contains a wildcard, but I haven't thought it through.
• [x] I haven't added a --sort option, but I have put a link to poetry-plugin-sort in the docs for ODEP006.
• [ ] pre-commit hook. I don't plan to do this, because I do not have a strong opinion exactly how the tool should be run on a given project, and hence I don't intend to specify a single "correct" command in the commit hook. This might be a philosophical divide between me and the authors of pre-commit, or maybe I just don't understand the tool well enough. If you'd get use from it and you want to do a PR then I'll consider it, but I might not want to maintain it indefinitely.