[Distutils] How to get list of package requirements from PyPI without downloading egg?
Phillip J. Eby
pje at telecommunity.com
Thu Oct 26 21:14:40 CEST 2006
At 10:20 AM 10/26/2006 -0600, Jeremy Kloth wrote:
>On Thursday 26 October 2006 9:21 am, Phillip J. Eby wrote:
> > At 12:53 AM 10/26/2006 -0600, Jeremy Kloth wrote:
> > >On Thursday 26 October 2006 12:21 am, Phillip J. Eby wrote:
> > No agreement on semantics simply means that the odds are astronomically
> > against anyone putting in data that can actually be used by someone else.
>As you like to point out so often, I do not actually recall anyone has ever
>brought up the semantics of the fields except yourself whom obviously is 110%
>against them to begin with.
> > You would *first* need to create a tool that could do something useful
> > the information,
>Done. 4Suite's PackageManager.
> > and second, you'd need it to be something that actually *tested* the
> > usefulness -- meaning you'd need a distutils extension,
>Done. See above.
Sounds great, then. What's the problem? (Btw, do you have a documentation
link? Google doesn't turn up anything except API docs that say nothing
about the PEP 314 stuff.)
> > install_requires is set by a script, so the script can set it based on the
> > Python version and platform the script is running on. Thus, eggs built for
> > different platforms or Python versions can have different requirements.
>And you're telling me that the `requires` argument isn't set by a script?
No, I'm saying that the Cheeseshop only holds one set of "requires" values.
>A platform/version specific dependency issue can only come into play if a
>particular distribution is begin scanned for dependencies out-of-band, which
>is what the OP was talking about, but that is not what is at issue here.
I was assuming we were talking about the OP's request, so that explains the
> > Until somebody has some idea of 1) what the semantics are, and 2) what the
> > use cases for those semantics are, the fields aren't of any value
> > whatsoever. This isn't something that's going to be improved by fiddling
> > with their syntax, so long as the semantics remain undefined.
>Aparently you haven't used a recent Linux distribution? Both apt or rpm have
>the semantics clearly defined and that is the first thing that came to my
>mind when I came across those fields.
Well, the PEP explicitly says there is *no* semantics defined, so I chose
to believe the PEP author. :) (Yes, I'm familiar with RPM-style
> Are you sure that you are not just against things that are not setuptools?
Quite sure. PEP 314 was the first place I looked for an opportunity to
implement setuptools' requirements. However, I found it to be inadequate
for my goals, which included backward-compatibility with existing
distutils-based packages, and support for simple, statically-published
package indexes and links. In essence, the "provides" portion of the PEP
makes it impossible (AFAICT) to provide these features. In my mind,
supporting discovery of non-setuptools packages and allowing distributed
package publishing was more important than mimicking RPM.
That's why I'm saying that getting PEP 314-based stuff out into the wild
requires either ignoring PEP 314's syntax restrictions (and the
provides/obsoletes fields along with them), or a break with both backward
compatibility and distributed publishing.
So, my opinion isn't really a matter of objecting to a "competing" system
(which would be silly). It's more a prediction that PEP 314 isn't really
going to go anywhere, because it imposes the cost of adoption on the wrong
people, without providing them any countervailing benefits. So it doesn't
take any great leap of intuition to see that it will go nowhere unless
That having been said, if I'm wrong and it *does* succeed in going
somewhere (e.g. the BDFL blesses some set of semantics), then I'll
certainly look at what needs to be done to add support for it to
setuptools. But at this point, it just looks to me like one of the
perennial "we should do something about X" ideas that doesn't go anywhere
because there isn't enough critical mass for adoption or anybody who knows
how to solve the technical problems.
More information about the Distutils-SIG