Re: Tool support for private modules

[Ben Finney <bignose+hates-spam@benfinney.id.au>]

Bernd, please follow the Debian mailing list code of conduct
<URL:http://www.debian.org/MailingLists#codeofconduct>, in particular
by *not* sending personal copies of messages that are also sent to the
list.

Also, please preserve attribution lines so we can keep track of who
wrote what quoted material.

Bernd Zeimetz <bernd@bzed.de> writes:

> > As an example, here's a Python package I'm trying to get packaged
> > for Debian. [...]
> >     <URL:http://cheeseshop.python.org/pypi/gracie/>
> 
> The first thing I'd do here is to patch the ez_ stuff away, together
> with setuptools.

I presume you mean the 'ez_setup.py' module (there's no other 'ez_*'
files in that package).

> ez_... is known to break things badly (like trying to download
> things on buildds and other really broken things). Setuptools is
> broken by design imho (see a thread some time ago about this), but
> it may work. But as I run into trouble with it too often (like
> missing __init__.py files in random directories), I replace it by
> distutils.

The main reason I use distutils is to assist those people using
operating systems that *don't* have good package dependency
management, which seems to be the primary target market for
setuptools.

I also want my package listed properly at the Python Cheeseshop; this
is much easier using setuptools than distutils.

> Since we're not building eggs there's not need for setuptools at all
> (afaik distutils is able to build eggs now, too - at least the egg
> info files, which is enough for us).  Better to patch those things
> before getting FTBFS reports form the buildds.

Okay. So you're suggesting that I should continue to maintain the
setuptools functionality upstream, but "patch it out" in the Debian
package of the same software?

I'm also unclear on what you mean by "replace it by distutils". What
does this mean for a package that already uses setuptools, and will
continue to do so upstream?

> Although I didn't test it, there should be no special thign to do with
> your setup.py while building a package, python setup.py build/install
> --root=.... should do the job (with and without ez_... and setuptools).

I'll address this in a separate thread, as it seems I'm not explaining
the problem very well.

-- 
 \      "I bought some powdered water, but I don't know what to add."  |
  `\                                                  -- Steven Wright |
_o__)                                                                  |
Ben Finney