On 22 Jul 2013 21:29, "Paul Moore" <p.f.moore@gmail.com> wrote:
>
> On 22 July 2013 12:22, Nick Coghlan <ncoghlan@gmail.com> wrote:
>>
>> since extras aren't really a thing in their own right (they're just a shorthand for referring to an additional set of dependencies)
>
>
> I'm still trying to be clear in my mind about what extras are, and how they should work. From this description, it occurs to me to ask, what is the difference between an extra and a (metadata only, empty) second distribution that depends on the base project as well as the "additional set of dependencies"? Is it just the admin overhead of registering a second project?

Sort of. The idea of an extra is "We have installed all the code for this, but it won't work due runtime failures if these dependencies aren't available".

With an actual separate distribution, you can't easily tell that the other distribution contains no code of its own, and naming and versioning gets more complicated. You also can't do the trick 426 adds where "*" means "all optional dependencies".

For other package systems like RPM that don't have the notion of extras, then yes, an extra would probably be mapped to a virtual package (in the specific case of yum, it copes fairly well with version locked virtual packages like that).

> Looking at extras this way gives a possible way of generating scripts only when the extras are present - just add the scripts to the dummy "extra" distribution.

Partial installs are problematic, since checking for optional dependencies is supposed to be a runtime thing, so it doesn't matter *how* those dependencies got there. Optional functionality like that would be better handled through a script that accepted subcommands, some of which would report an error if dependencies were missing.

For a truly optional script, then it needs to be a genuinely separate package.

Cheers,
Nick.

>
> Paul.