On 4 March 2013 20:00, Daniel Holth wrote:

On Mon, Mar 4, 2013 at 2:41 PM, Paul Moore wrote:

...

In thinking about how virtualenv would describe the packages it wants to preload in PEP 426 metadata form, it occurred to me that there are scenarios with setuptools and distribute where it's not obvious how to state the requirement you want. Specifically, if you want to install setuptools if it is present, but if not fall back to distribute (for example, if you have a local package repository and no access to PyPI, but setuptools may or may not be present). [...]

We do have Provides-Dist, although the best way to implement it is an open question.

Good point. So distribute would have "Provides-Dist: setuptools" and I could just require setuptools. Given that none of this is supported yet, I'm happy that the spec covers this case, but still need to work around it for the immediate future. Thanks, Paul

On 5 Mar 2013 06:55, "PJ Eby" wrote:

On Mon, Mar 4, 2013 at 2:41 PM, Paul Moore wrote:

...

In thinking about how virtualenv would describe the packages it wants to preload in PEP 426 metadata form, it occurred to me that there are scenarios with setuptools and distribute where it's not obvious how to state the requirement you want. Specifically, if you want to install setuptools if it is present, but if not fall back to distribute (for example, if you have a local package repository and no access to PyPI, but setuptools may or may not be present).

I appreciate this is a fairly obscure case. It comes up with virtualenv because virtualenv uses locally-available distributions by default, only going to PyPI if it has to. So in that case (depending on user options) I could genuinely want to pick whichever of setuptools or distribute is present, and I don't care which, as it saves a network lookup.

I'm actually using the distlib locator API, not the PEP 426 fields themselves, but (a) distlib locators use the same syntax, as far as I'm aware, and (b) I think the Requires-Dist syntax makes a good language for specifying distribution requirements in any context, so I'd hate to end up with 2 slightly-different forms.

If the answer is that the spec doesn't support that, then fine. I'll have to manually code for it. But I'd hate to write code I didn't need to :-)

This is a good point; people have been wanting setuptools to support alternate dependencies (i.e., I need this *or* that) for a long time, and not just for that particular use case.

PEP 426 has another similar-but-not-identical problem: the current version doesn't have a particularly clean way to write "2.6+ or 3.2+" for the Requires-Python field. Cheers, Nick.

_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig

On 6 Mar 2013 00:59, "PJ Eby" wrote:

On Mon, Mar 4, 2013 at 3:20 PM, Paul Moore wrote:

...

On 4 March 2013 20:00, Daniel Holth wrote:

...

On Mon, Mar 4, 2013 at 2:41 PM, Paul Moore wrote:

...

In thinking about how virtualenv would describe the packages it wants to preload in PEP 426 metadata form, it occurred to me that there are scenarios with setuptools and distribute where it's not obvious how to state the requirement you want. Specifically, if you want to install setuptools if it is present, but if not fall back to distribute (for example, if you have a local package repository and no access to PyPI, but setuptools may or may not be present). [...]

We do have Provides-Dist, although the best way to implement it is an open question.

Good point. So distribute would have "Provides-Dist: setuptools" and I could just require setuptools. Given that none of this is supported yet, I'm happy that the spec covers this case, but still need to work around it for the immediate future.

Provides-Dist doesn't actually work for most of the use cases for alternates, though. For example, if a package that wants to require one of the various mysql adapters, it doesn't make any sense for the mysql packages to declare that they provide each other. ;-)

The adapter developers just need to agree on a virtual provides they will all publish. Of course, that won't be effective without an entry points extension to get the adapters loaded in a consistent fashion. Still, one step at a time :) Cheers, Nick.

_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig