Re: Tool support for private modules
Bernd, please follow the Debian mailing list code of conduct 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 <[EMAIL PROTECTED]> writes: > > As an example, here's a Python package I'm trying to get packaged > > for Debian. [...] > > 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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Packaging software for Cheeseshop and Debian
Howdy all, In the thread Message-ID: <[EMAIL PROTECTED]>, I asked about package-private modules interacting with setuptools and the Debian Python policy. In retrospect it seems I've got some more fundamental learning to do. I'm not well-versed in Python setuptools or distutils, so I'm probably making many mistakes. I've read the documentation for both, but it's not gelling in my mind. Moreover, I want to package software using setuptools *and* package the same software for Debian. Hence, I run into the issues familiar to most on this list, where the practices of setuptools users and developers clash with the practices of Debian packaging. There doesn't seem to be a great deal of common ground: most of what the setuptools folks recommend is contradicted by what the Debian packagers of Python software recommend. No doubt both have their good and bad arguments for their way of doing things. Meanwhile, I'm stuck trying to learn how to satisfy both, because complying with active conventions and standards is valuable enough to work at. So, I ask for help with this specific package, in the hope that I can learn more general lessons about packaging software for both Python's Cheeseshop and the Debian package system. http://cheeseshop.python.org/pypi/gracie/> http://pypi.python.org/packages/source/g/gracie/gracie-0.2.5.tar.gz> When I run './setup.py bdist_egg', I get an egg containing *only* the modules, not the program 'bin/gracied'. What am I doing wrong that is omitting the program from the package? How do I ensure that it will be installed properly from the package? Also, when installing this package, the destination for the modules is the system 'site-packages' directory. These modules, though, are specific to this package and its programs; I'd prefer to have them installed to a different place, but have no idea how to specify that as part of the package metadata or in the 'setup.py'. (I'm *not* talking about the install-time option of *overriding* the default location, but rather to set the location default in the 'setup.py' or other package configuration.) As for packaging this for Debian, what do I need to do in addition to addressing the above? Bear in mind that I intend to continue maintaining this as a setuptools package "upstream", for two reasons: I want the benefits of setuptools as already described elsewhere, and I want to know how to do this when I'm *not* the upstream developer. Thanks for reading, and I hope my learning process can be instructive to others. -- \ "Once consumers can no longer get free music, they will have to | `\ buy the music in the formats we choose to put out." -- Steve | _o__) Heckler, VP of Sony Music, 2001 | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Tool support for private modules
Ben Finney <[EMAIL PROTECTED]> writes: > 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. This should, of course, read "The main reason I use setuptools …" -- \ "Pinky, are you pondering what I'm pondering?" "I think so, | `\Brain, but this time *you* put the trousers on the chimp." -- | _o__)_Pinky and The Brain_ | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
