[Python-Dev] Keyword meanings [was: Accept just PEP-0426]

Nick Coghlan ncoghlan at gmail.com
Sat Dec 8 02:49:29 CET 2012


On Sat, Dec 8, 2012 at 8:02 AM, PJ Eby <pje at telecommunity.com> wrote:

> > *) Not all packages built build on top of that system.  There are rpm
> > packages provided by upstreams that users attempt (to greater and lesser
> > degrees of success) to install on SuSE, RHEL, Fedora, Mandriva, etc.
>  There
> > are debs built for Ubuntu that people attempt to install onto Debian.
>
> Sure.  But the reference points still exist, and there is a layer of
> indirection between "packager" and "developer", even in the case where
> the packager and developer are the same person or organization.  In
> the Python case, there is usually no such indirection, outside of
> curated systems like SciPy et al.  (Even there, most of what
> third-party packaging is about in the Python world is taking care of
> binary builds.)
>
> Again, it's islands in the ocean vs. pools on land.
>

To strain the analogy, the main value of these fields exists on the beach:
at the point where you need to impedance match between the Python community
and another packaging community.

The ideal is to be able to get a point where you can point an automated
tool at a project on PyPI and say "give me that, only packaged as
RPM/deb/whatever, with appropriate distro specific metadata". Such a tool
is obviously going to be distro specific, since it is going to have to do
some remapping based on file names to pick up existing distro packages, but
it *also* needs upstream metadata.

Even in a distro, a "Conflicts:" field often *does* denote runtime
conflicts (e.g. over a particular network port), because, as you say,
filesystem level conflicts will usually be picked up automatically. The
distro philosophy is to say "OK, we simply won't let you install
conflicting projects at the same time, so you won't be surprised later by a
conflict that only shows up if you happen to run them both at the same
time". It's designed to turn a complex, hard to debug, problem into a
simple, explicit error at installation time.

People build complex systems (especially web apps) based on the PyPI
ecosystem, and the upstream communities *can* assist in flagging potential
issues in advance. If people start putting bad metadata in their projects,
then that's just a bug to be dealt with like any other.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20121208/9edc4940/attachment.html>


More information about the Python-Dev mailing list