#default extras
1 messages · Page 1 of 1 (latest)
i created https://discuss.python.org/t/proposal-expanding-optional-dependencies-to-support-opt-out-of-recommended-default-installables/26617 for the less controversial part
what if the +/- signs could be used to define extras that install by default or get a opt-out for example [project] name = "fun" [project.optional_dependencies] "+cli" = [ "rich" ] then asking for fun should imply fun[cli] but asking for fun[-cli] would opt out of the auto-add it could also be spelled as [project] name = "fun" [project.reco...
Hi everyone, first message to this forum. I hope this will be compliant with the expected format. There has been a number of discussion opened for a long time on this topic: https://github.com/pypa/setuptools/issues/1139 (opened for 3 years). Possible default extras/dependency categories? Somehow related, I opened yesterday an issue on Gith...
the default extras proposed by @analog lily seem superior for the definition, i'll link it
that thread is quite a few bikes turned dust
well, it's easy to toss ideas around but very few people wanna go through the PEP process 😛
(as a general observation, didn't mean Pradyun specifically)
so whats needed is a pep for default extras which adds the metadata, pyproject toml mapping, requirement specifiers extension and some coordination with pradyun as it seems like life has been unkind to his intent to do the pep
I have a draft PEP somewhere for this.
And, if someone wants to write a PEP for this, I'd be more than happy to co-author or sponsor it (whichever works best!).
I'd appreciate to see this somewhere
I'm interested in helping this along but it's also tricky to commit until October
@analog lily i threw together a really basic starting point in https://github.com/RonnyPfannschmidt/python-peps/pull/1 - i'll try to refine it a bit over the next few days and then send out messages to discuss it once its a bit more coherent
@analog lily I'd like to see your draft for reference if feasible
Am away from my personal keyboard
in that case, i suppose its best to wish you fun while away from the box of creation and despair ^^
Looks like I only titled the PEP (Default optional dependencies for Python Packages) and wrote a rough draft of an abstract.
Many Python packages provide optional functionality that is conditionally available, based on what dependencies are installed. This is enabled by having optional dependencies (via extras) get installed using
package[extra1, extra2]syntax from :pep:508.This PEP provides the ability for packages to specify certain extras to get selected for installation by default, through a new
Default-Extraskey in Core Metadata. It also extends the dependency specification syntax to enable un-selecting a selected-by-default extra (via a newpackage[-extra1]syntax).
Feel free to use that with whatever level of attribution you want (including none), if you build off of that. If you wanna co-author this, or need a sponsor, lemme know. :)
default extras
I'll hold off on touching this until @manic dome says something, or it's Aug 2023. :)
Coincidentally My paternity leave ends on the 8th of August
@analog lily I'm most vexed with the topic,
No matter how I roll it around, having recommend/default Extras separate is a backwards compatibility pain and having them merged and splitting in updated resolvers is a unhinged complexity trap