[Distutils] How to get list of package requirements from PyPI without downloading egg?

[Phillip J. Eby]

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 
> with
> > 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 
disconnect.


> > 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 
requirements.)


>  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 
something changes.

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.