On 11 March 2017 at 07:03, Daniel Holth <dho...@gmail.com> wrote:
> You lost me a bit at 'extra sets'. FYI it is already possible to depend on
> your own extras in another extra.
>
> Extra pseudo code:
> spampackage
> extra['spam'] = 'spampackage[eggs]'
> extra['eggs'] = ...
>
Oh, nice. In that case, we can drop the '*' idea and just make "all"
another pre-declared extra with a SHOULD that says sdist build tools should
implicitly populate it as:
{
"requires": "thisproject[extra1,extra2,extra3,extra4]"
"extra": "all"
}
given an extras clause containing '["extra1",'extra2","extra3","extra4"]'.
Endorsing that approach to handling "extra sets" does impose a design
constraint though, which is that installation tools will need to
special-case self-referential requirements so they don't get stuck in a
recursive loop. (That will become a new MUST in the spec)
That just leaves the question of how to install build & test requirements
without installing the project itself, and I guess we don't actually need
to handle that at the Python metadata level - it can be done by external
tools. For example, in the pyp2rpm case, it's handled by the translation to
BuildRequires and Requires terms at the RPM level, with RPM then handling
the task of setting up the build environment correctly.
> +1 on extras. The extras feature has the wonderful property that people
> understand it. Lots of projects have a 'test' extra instead of
> tests_require for example, and you don't have to look up how to install
> them.
>
Yeah, it was really helpful to me to work through the "How would I replace
this proposal with the existing extras system?", since the end result
achieved everything I was aiming for without requiring any fundamentally
new concepts or tech.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
_______________________________________________
Distutils-SIG maillist - Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig
