Mailman 3 Python Deb Packages - Distutils-SIG

newer
setuptools vs distribute on Debian

Python Deb Packages

Damian Johnson

16 Nov 2010 16 Nov '10

7:13 p.m.

Hi, I'm working on deb/rpm packaging for a terminal monitor of tor relays [1] and running into an issue with the egg-info distutil autogenerates. My project currently installs to the default '/usr/share/pyshared' [2] but according to the debian policy for private python modules [3] it should be installed to '/usr/share' instead (my program is an application and there's no reason for it to be importable by other modules). The problem with doing this is that the egg-info metadata is hardcoded in 'distutils/command/install.py' to be added on install, and having an egg-info file on '/usr/share' causes a lintian error when generating the deb. Also, most things I've been reading seems to say that the package belongs in '/usr/share/pyshared' and that removing the egg-info is kinda evil [4]. Help would be appreciated. Cheers! -Damian [1] http://www.atagar.com/arm/ [2] https://svn.torproject.org/svn/arm/trunk/setup.py [3] http://www.debian.org/doc/packaging-manuals/python-policy/ch-programs.html#s... [4] http://mail.python.org/pipermail/distutils-sig/2007-September/008225.html

Attachments:

attachment.html (text/html — 1.5 KB)

Show replies by date

Piotr Ożarowski

17 Nov 17 Nov

11:29 a.m.

[Mail-Followup-To set to debian-python@lists.debian.org] [Damian Johnson, 2010-11-16]

...

My project currently installs to the default '/usr/share/pyshared' [2] but

/usr/share/pyshared is Debian tools' internal location and you should not use it (i.e. it's not and will never be in sys.path)

...

according to the debian policy for private python modules [3] it should be installed to '/usr/share' instead (my program is an application and there's

/usr/share/binary_package_name/ to be exact

...

no reason for it to be importable by other modules). The problem with doing this is that the egg-info metadata is hardcoded in 'distutils/command/install.py' to be added on install, and having an egg-info file on '/usr/share' causes a lintian error when generating the deb.

--install-lib=/usr/share/yourpackagename/ --install-data=/usr/share/yourpackagename/ (and maybe --install-scripts=/usr/share/yourpackagename/) should do the right thing (i.e. don't install directly to /usr/share/ as it could couse namespace prioblems with other private modules) -- Piotr Ożarowski Debian GNU/Linux Developer www.ozarowski.pl www.griffith.cc www.debian.org GPG Fingerprint: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645

Damian Johnson

4:25 p.m.

...

/usr/share/pyshared is Debian tools' internal location and you should not use it

Great, thanks Piotr for the clarification.

...

/usr/share/binary_package_name/ to be exact --install-lib=/usr/share/yourpackagename/ --install-data=/usr/share/yourpackagename/ (and maybe --install-scripts=/usr/share/yourpackagename/) should do the right thing

Unfortunately not quite. Passing those flags results in: /usr/share/arm/arm/ /usr/share/arm/arm-1.3.7_dev.egg-info The egg-info metadata only has relevance if this was being installed to pyshared so ideally it should be omitted and the package contents just installed to: /usr/share/arm/ Setting "--install-lib=/usr/share" adds my package to the right location, but also includes "/usr/share/arm-1.3.7_dev.egg-info" which causes a lintian error. A couple quick questions: - If private python modules aren't supposed to be living in '/usr/share/pyshared' then shouldn't distutil include an option to omit the egg-info metadata? - Any ideas you have for how to remove the egg-info during debian builds would be much appreciated. Peter has mentioned that a simple change to the debian/rules [1] should do the trick but I'm still a bit too new to debian builds to know what. Cheers! -Damian [1] https://svn.torproject.org/svn/arm/resources/build/debian/rules On Tue, Nov 16, 2010 at 11:13 AM, Damian Johnson wrote:

...

Hi, I'm working on deb/rpm packaging for a terminal monitor of tor relays [1] and running into an issue with the egg-info distutil autogenerates.

My project currently installs to the default '/usr/share/pyshared' [2] but according to the debian policy for private python modules [3] it should be installed to '/usr/share' instead (my program is an application and there's no reason for it to be importable by other modules). The problem with doing this is that the egg-info metadata is hardcoded in 'distutils/command/install.py' to be added on install, and having an egg-info file on '/usr/share' causes a lintian error when generating the deb. Also, most things I've been reading seems to say that the package belongs in '/usr/share/pyshared' and that removing the egg-info is kinda evil [4].

Help would be appreciated. Cheers! -Damian

[1] http://www.atagar.com/arm/ [2] https://svn.torproject.org/svn/arm/trunk/setup.py [3] http://www.debian.org/doc/packaging-manuals/python-policy/ch-programs.html#s... [4] http://mail.python.org/pipermail/distutils-sig/2007-September/008225.html

Piotr Ozarowski

18 Nov 18 Nov

1:10 p.m.

[Damian Johnson, 2010-11-17]

...

...
--install-lib=/usr/share/yourpackagename/ --install-data=/usr/share/yourpackagename/ (and maybe --install-scripts=/usr/share/yourpackagename/) should do the right thing

Unfortunately not quite. Passing those flags results in: /usr/share/arm/arm/ /usr/share/arm/arm-1.3.7_dev.egg-info

... and that's perfectly fine (if the first "arm" is (Debian) package name)

...

The egg-info metadata only has relevance if this was being installed to pyshared so ideally it should be omitted and the package contents just installed to: /usr/share/arm/

You can remove it in debian/rules (see below) if you want (if it's not used in the module), keeping it shouldn't harm, though

...

Setting "--install-lib=/usr/share" adds my package to the right location, but also includes "/usr/share/arm-1.3.7_dev.egg-info" which causes a lintian error. A couple quick questions:

What if package foo will install private module "arm" in /usr/share/ as well? Please don't do that unless there's a really good reason to take over a namespace

...

- If private python modules aren't supposed to be living in '/usr/share/pyshared' then shouldn't distutil include an option to omit the egg-info metadata?

Are you sure this data isn't used? An option to disable .egg-info file/directory generation would be nice, though.

...

- Any ideas you have for how to remove the egg-info during debian builds would be much appreciated.

How about something like this (I didn't test it): | #!/usr/bin/make -f | %: | dh $@ --with python2 | | override_dh_auto_install: | python setup.py install --install-lib=/usr/share/foo/ --install-data=/usr/share/foo/ --install-scripts=/usr/share/foo/ | dh_link /usr/share/foo/myscript /usr/bin/myscript | rm -rf debian/foo/usr/share/foo/arm*info replace foo with [Debian] binary package name; instead of dh_link line you can add debian/links file -- Piotr Ożarowski Debian GNU/Linux Developer www.ozarowski.pl www.griffith.cc www.debian.org GPG Fingerprint: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645

Piotr Ozarowski

1:37 p.m.

[Piotr Ozarowski, 2010-11-18]

...

| python setup.py install --install-lib=/usr/share/foo/ --install-data=/usr/share/foo/ --install-scripts=/usr/share/foo/

add "--root=debian/foo" to that line -- Piotr Ożarowski Debian GNU/Linux Developer www.ozarowski.pl www.griffith.cc www.debian.org GPG Fingerprint: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645

4907

Age (days ago)

4909

Last active (days ago)

List overview

Download

4 comments

3 participants

participants (3)

Damian Johnson
Piotr Ozarowski
Piotr Ożarowski

Python Deb Packages

Damian Johnson

Piotr Ożarowski

Damian Johnson

Piotr Ozarowski

Piotr Ozarowski

tags

participants (3)