Reinvent no more forever

[Fuzzyman]

Ben Finney wrote:
> Howdy all,
>

Hello,

> On dirtSimple.org[0], PJE wrote:
>
>     "Why is Python "blessed" with so much reinvention? Because it's
>     often cheaper to rewrite than to reuse. 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.

>         3. make your users do all the work themselves
>
>     Ouch. No wonder rewriting looks easier."
> [snip..]
> I now have a setuptools package of my Enum implementation. Should I
> submit it to PyPI?
>
> Advantages:
>
>   - I can declare a dependency on that package for all my other
>     packages that need such functionality, instead of bundling it
>     every time.
>
>   - Others can benefit from my code, instead of yet again including an
>     Enum implementation (home-grown, or picked from a cookbook) by a
>     simple dependency declaration.
>
>   - The code hopefully gets improved and generalised and all the other
>     benefits that accrue to software with many users.
>

These are all very compelling reasons.

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

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

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

> 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.
>
> I'd love to follow the mantra PJE espouses, but if it's good for one
> person it's probably good for countless others. How do we deal with
> that? What actions can we take in advance to prevent problems in
> future?
>

Isn't setuptools *the system* that addresses these issues ? It provides
a way to track and auto-install dependencies  - so long as you have the
right kind of netowrk connection [1] and the packager of the
dependencies provides them in a way compatible with setuptools.

All the best,

Fuzzy
http://www.voidspace.org.uk/python/index.shtml

[1] setuptools uses python code to access the internet and install
dependencies. Python code can't fetch https URLs through a proxy and
can't use a SOCKS proxy at all. That means with some kinds of internet
conenctions (e.g. behind company firewalls) it doesn't work. Building
optional support for pycurl into setuptools could possibly resolve
this.

>
> [0] <URL:http://dirtsimple.org/2005/07/reinvent-no-more-forever.html>
>
> [1] Of course, someone already has. I prefer mine to theirs, hence the
> question.
>
> --
>  \         "I planted some bird seed. A bird came up. Now I don't know |
>   `\                               what to feed it."  -- Steven Wright |
> _o__)                                                                  |
> Ben Finney