Packaging python bits with setuptools that depend on non-distutil packages
Toshio Kuratomi
a.badger at gmail.com
Mon May 4 15:17:22 UTC 2009
loupgaroublond at gmail.com wrote:
> Hey List,
>
> I'm working on a couple of projects to get them to use setuptools, but
> i've come across an interesting dillema. Some core systems modules, such
> as dbus and rpm aren't normally provided as eggs, because they are built
> as part of the build process of the original C code. This yields two
> issues.
>
> 1) I cannot use virtualenv to test these packages in a clean room. I
> like to test things in as clean of an area as possible, and sometimes
> it's difficult to figure out what i've installed might be modifying some
> expected behavior. Virtualenv let's you build very light weight
> containers for testing python code in, but without distutils, it's hard
> to run some setup script or rely on easy_install to provide the needed
> bits.
>
easy_install is of only marginal use when dealing with modules that have
to be compiled. Getting built eggs for that case is going to be a hard
sell.
> 2) How do we normally declare dependencies on these components in
> setuptools? If i were to push the package i'm making to the Python
> Cheese shop, it would depend on something the user may not actually have
> installed. How do i go about declaring these dependencies?
>
The best thing to do is to not depend on those packages that do not
provide egg-info. Trying to describe a dependency on them in the
setup.py is doing no one any favors (as your user's cannot satisfy the
dependencies so they cannot ever install this.)
> To make a short story long, i'm sure there are ways to include code
> snippets in dbus, rpm, and possibly other packages that also generate
> egg info. This would at least let me declare those packages as
> dependencies. The bigger issue i have though, is how can i import them
> in some generic fashion into virtualenv?
>
Now that that's out of the way.... look at pygobject2 for some Makefile
rules that may help you.
-Toshio
More information about the fedora-devel-list
mailing list