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. _______________________________________________ Distutils-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/distutils-sig
