[a.bad...@gmail.com: Switching python-setuptools source to distribute]
JFYI, and just in case nobody of the -python regulars are subscribed to
distributi...@fd.o
Cheers.
- Forwarded message from Toshio Kuratomi -
Date: Thu, 15 Oct 2009 11:25:49 -0700
From: Toshio Kuratomi
To: distributi...@freedesktop.org
Subject: Switching python-setuptools source to distribute
Greetings all, this is mostly for the python packagers amongst you.
In recent yesrs many python packages have come to rely on the setuptools
module to build and install (and for some it's a runtime requirement as
well). However, setuptools development is really a one-man show where that
one man has been a bottleneck for development and bug fixing of the code.
So, after many years of complaints and sporadic setuptools releases, a fork
of the project named distribute was created. This fork installs into the
same module name as the current setuptools package and the same API,
transparently replacing it. It has an active group of core committers and
has made several releases over the past few months. The lead on the project
is also the new distutils maintainer in the pyhton stdlib and has expressed
interest in making packaging python modules more compliant with the needs of
Linux distributions (although the present release series aims to maintain
compatiblity with setuptools, so there's only so much that can be done
there.)
Since setuptools is such a widely used module I'm wondering how other
distributions are choosing to package setuptools/this fork. From a message
on the distutils-sig mailing list I'm lead to believe that Gentoo's latest
setuptools packages are distribute-based. I've just done the same for the
development package in Fedora 13 (over six months away). Are other
distributions moving in the same direction? Going to stick with the
setuptools upstream? Work on making a parallel installable version? Or
leaving it entirely up to their setuptools packager to make the decision?
http://pypi.python.org/pypi/setuptools
http://pypi.python.org/pypi/distribute
-Toshio
___
Distributions mailing list
distributi...@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/distributions
- End forwarded message -
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..| . |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...| ..: | Je dis tu à tous ceux que j'aime
signature.asc
Description: Digital signature
Re: [a.bad...@gmail.com: Switching python-setuptools source to distribute]
see #546452 (we'll replace setuptools with distribute as well) -- 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 -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Joining the DPMT (Bug#551038: ITP: python-scrapy -- Python web scraping and crawling framework)
On Thu, Oct 15, 2009 at 20:55, Piotr Ożarowski wrote: > Hi Ignace, Hello, > Welcome in the team :-) Thank you! :) Regards, Ignace M -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: RFS: python-coverage 3.0.1-1
[Ben Finney, 2009-10-16] > Piotr Ożarowski writes: > > > [Ben Finney, 2009-10-02] > > > $ dget > > > http://mentors.debian.net/debian/pool/main/p/python-coverage/python-coverage_3.0.1-1.dsc > > > > * why 2.3-2.6 in pyversions? Will it not work with 2.7? Do not worry about > > Python >= 3 (modules for py3k will be shipped in python3-coverage) > > That range of versions is what upstream declares support for. Python 2.7 > is not on their list of supported versions. if there are no known problems, please use "2.3-" - this way we'll have less work while adding 2.7 to the supported versions > > * how about adding -dbg package? > > Good idea, thanks. I've never looked into how that's done. Where should > I begin reading about it? > > Once I learn how to make a ‘foo-dbg’ package, I can do that in the next > release (see below). IIRC you're using dh sequencer, so just add -dbg package in debian/control, build depend on python-all-dbg and dh will do the rest -- 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 -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Fw: RFS: python-coverage 3.0.1-1
It seems my message didn't passed through, so I re-send it, I hope with a better fate. Data: Sat, 3 Oct 2009 11:43:25 +0200 Da: Luca Falavigna A: Ben Finney Cc: debian-ment...@lists.debian.org, debian-python@lists.debian.org Oggetto: Re: RFS: python-coverage 3.0.1-1 Hi Ben, I reviewed a bit python-coverage, here are some suggestions: debian/control: * Build-Depend on debhelper (>= 7.3.5). debian/python-coverage.dirs: * Useless. debian/python-coverage.install: * I'd use debian/manpages to install python-coverage.1. debian/rules: * Why did you rename /usr/bin/coverage to /usr/bin/python-coverage? * Pass --single-version-externally-managed to setup.py install. * You could eventually adopt rules.tiny to simplify reading. debian/watch: * "Newest version on remote site is 3.1~b1, local version is 3.0.1", you could want to exclude beta releases. -- .''`. : :' : Luca Falavigna `. `' `- signature.asc Description: PGP signature
Re: Fw: RFS: python-coverage 3.0.1-1
Luca Falavigna writes: > It seems my message didn't passed through, so I re-send it, I hope > with a better fate. We got it this time. Thank you for inspecting this package. > debian/control: > * Build-Depend on debhelper (>= 7.3.5). The changelog entry for ‘debhelper’ 7.3.5 says: * python_distutils buildsystem: Build for all supported Python versions that are installed. Ensure that correct shebangs are created by using `python' first during build and install. Closes: #520834 Also build with python*-dbg if the package build-depends on them. What does it mean “if the package build-depends on them”? If “them” means “debug packages”, why would any non-debug package depend on a debug package? > debian/python-coverage.dirs: > * Useless. I can't find where ‘/usr/bin/’ is excluded from requirement to be created; is it in a part of Policy that I've overlooked? > debian/python-coverage.install: > * I'd use debian/manpages to install python-coverage.1. Done. > debian/rules: > * Why did you rename /usr/bin/coverage to /usr/bin/python-coverage? Because ‘/usr/bin/coverage’ is far too generic a name for a tool specifically for checking Python source code. (This change was made before I started maintaining the package, but I agree with it on this rationale.) > * Pass --single-version-externally-managed to setup.py install. The package doesn't directly use ‘setup.py install’ at all, leaving that to the various ‘debhelper’ programs. In what circumstances does a package need your suggested change to override what those helpers do by default? > * You could eventually adopt rules.tiny to simplify reading. That template omits the ‘.PHONY’ rules (marking some targets as phony so they will be built regardless whether there is a file of the same name). I think those rules serve a good purpose, so I use a ‘debian/rules’ file that declares them. > debian/watch: > * "Newest version on remote site is 3.1~b1, local version is 3.0.1", >you could want to exclude beta releases. I prefer to make this determination for each release, rather than have them omitted by default. Is there a reason this is a bad practice? Thanks again for your feedback. -- \ “Shepherds … look after their sheep so they can, first, fleece | `\ them and second, turn them into meat. That's much more like the | _o__) priesthood as I know it.” —Christopher Hitchens, 2008-10-29 | Ben Finney pgpQxLaodJeyl.pgp Description: PGP signature
