Reinvent no more forever

[Ben Finney]

Fuzzyman <fuzzyman at gmail.com> wrote:
> Ben Finney wrote:
> > On dirtSimple.org[0], PJE wrote:
> >
> >     [...] Python code is easy to write, but hard to depend on. You
> >     pretty much have to:
> >
> >         1. limit yourself to platforms with a suitable packaging
> >         system,
> >         2. bundle all your dependencies into your distribution, or
> 
> For pure python modules I don't find this to be a big problem.

The problem isn't whether it's Python or not; the problem is the
complexity of the code base. A simple application that depends on
infrastructure from five different non-standard packages becomes a
right mess to distribute, is stuck with code that is peripheral to its
own purpose, and can't benefit from new versions of those packages.

> > [distributing a simple package via PyPI]
> >
> > Disadvantages:
> >
> >   - Proliferation. What's the protocol when[1] someone else puts
> >   an (incompatible, differently-specified) Enum implementation
> >   into PyPI?
> 
> That shouldn't be any more of a problem than the current situation.
> In fact as the setuptools system becomes more established then it
> should be easier for people to discover that an existing package
> does what they want - rather than creating their own.

I hold up all existing public source code repositories as evidence
against your prediction. Reinventing the wheel is distressingly
common, and a dependency tool isn't going to stop that.

> >   - Naming. How many ways can a package providing an Enum be
> >   named? I'd prefer mine to be named "Enum" or "enum", but why
> >   should mine be the one that claims that name?
> 
> I think "first come - first served" is the only possible way this
> can work.

Perhaps so.

> >   - It's just a pretty simple type, with unit tests. Does this
> >   really justify a PyPI package?
> 
> If it solves a common problem in an elegant way, then it's better
> shared. :-)

Sure. But the question was, is PyPI the place to do so?

> > This is common to any repository of code. But the "automatic
> > dependency" problem means that all those packages, and many more
> > outside that repository, need to know how those problems are
> > resolved.
> >
> > Operating system distributors have policies (to greater or lesser
> > degrees of strictness) to ensure this kind of quality control. My
> > understanding of PyPI is that there's no such policy.
> 
> Isn't setuptools *the system* that addresses these issues ? It
> provides a way to track and auto-install dependencies [...]

No, setuptools is only the answer for the packages themselves; the
problems I describe are inherent to the package repository.

The setuptools dependency model rests on the reliability of the
package repository. Not only in terms of availability but also in
terms of the quality and functionality of the package set.

-- 
 \         "I went to the museum where they had all the heads and arms |
  `\   from the statues that are in all the other museums."  -- Steven |
_o__)                                                           Wright |
Ben Finney