Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Machine-readable dump of the defined sessions #648

Closed
ppentchev opened this issue Aug 31, 2022 · 3 comments
Closed

Machine-readable dump of the defined sessions #648

ppentchev opened this issue Aug 31, 2022 · 3 comments

Comments

@ppentchev
Copy link

How would this feature be useful?

Hi,

First of all, thanks a lot for writing and maintaining Nox!

What do you think about a possible enhancement: add a couple of options to nox --list to make it output the session data (at least the names and the tags, maybe the function names and/or signatures) in a machine-readable format? My main use case would be something like the nox-stages utility that I just wrote - https://gitlab.com/ppentchev/nox-dump or more precisely https://gitlab.com/ppentchev/nox-dump/-/blob/main/src/nox_dump/stages/__main__.py and its sibling files - so that I can do something like nox-stages @check @tests and have it only run the time-consuming unit tests if the static checkers like mypy and pylint are happy with my changes. Right now, nox-stages obviously uses the nox-dump module that shamelessly sticks its grubby mitts into the internals of nox.registry, and I can imagine how that might not be seen as a viable long-term-supportable API-chasing approach, although I personally would be happy to commit to doing that (including the chasing of API and code internals changes) if you have no strong objections.

Describe the solution you'd like

Still... I wonder if it might not be better to implement this in Nox itself. Would you like me to try to come up with a proof of concept that adds, say, a --toml or --json or -f toml or similar option to nox --list? If so, here are a couple of questions, since you might not want the kind of overengineering that I sometimes do to future-proof the very first version of my projects :)

  • what fields would it be a good idea to include in the output? nox-dump currently goes for a lot, but it's fine if you do not really share my view of what is necessary and what is still internal and subject to change
  • what do you think about the idea of including a format: version: major: 1, minor: 0 part to handle future added fields (bumping the minor format version) or changed fields (bumping the major one)?
  • would a dependency on the toml library be okay for TOML output?
  • would some kind of human-readable output, like TSV or CSV or something, be desired, likely with a name like "csv1" to allow for future formatting changes?
  • if so, what should it include - function name, description, maybe the tags? maybe the function signatures?
  • and how should it be formatted - there are various not-really-compatible CSV-like formats out there, with various ideas about quoting, allowed special characters, etc?

Describe alternatives you've considered

Of course, a "nah, it's too early yet, nothing is stable enough to commit to a stable output format" answer would be just fine, in which case I can maintain nox-dump externally if that's okay.

...and if it turns out that I have missed some Nox command-line option and that it can already do what I want... ooooooof :)) yeah, that would be just like me :))

Anything else?

Thanks again, and keep up the great work!

G'luck,
Peter

@ppentchev
Copy link
Author

Hi,

I'd like to apologize if my chosen wording came off as condescending or offensive. When I asked if you'd like me to put together a proof of concept, what I meant was, it would be great if something like that were implemented and - if you want - you can offload some of the work on me. Of course I know you're more than capable of implementing things like that yourself if you want to.

So once again, apologies, and thanks for writing Nox!

G'luck,
Peter

@ssbarnea
Copy link

This issue is currently a blocking for pycontribs/mk#141

@FollowTheProcess
Copy link
Collaborator

FYI this is already merged #665 and will be in the next release

@henryiii henryiii closed this as completed Apr 6, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Development

No branches or pull requests

4 participants