|
 |
|
 |
|
to distribute_setup() or not, that is the question
|
|
On Thu, 26 Jan 2012 17:06:20 -0500, Barry Warsaw <...@python.org
I've had a few conversations about this between Scott and Jakub, but I think
it's worth opening up to all of debian-python.
Upstream, my flufl.* packages all have the following two lines at the top of
their setup.py files:
-----snip snip-----
import distribute_setup
distribute_setup.use_setuptools()
-----snip snip-----
This is useful when developing the package because it ensures that I'll have a
new enough distribute when doing upstream development. In fact, if a new
enough distribute is not available, one will be downloaded from the
Cheeseshop. This works great for platform-independent upstream development.
It does not work so well for packaging on Debian though. The biggest problem
is that if you build this package on an older version of Debian, you'll end up
downloading distribute from PyPI during the build process, which
understandably is a no no.
Note that if you build the current-in-svn flufl.enum for example, on Wheezy
you'll be fine, because it has a newer distribute than the minimum
requirement. If you build it on Squeeze however, you get the download.
One partial solution to this is to set the minimum version in the d/control's
B-D so that at least on Squeeze, the build will fail instead of downloading:
Build-Depends: python-all ( python-setuptools ( python-pkg-resources,
python-sphinx ( debhelper ( python3-all,
python3-setuptools ( python3-pkg-resources
Given that I really don't want to change upstream, the question then is what
the best approach is for the Debian packaging.
1) Leave it as above because it's okay that the build fails on Squeeze.
2) Add a quilt patch to comment out the distribute_setup lines above, and then
don't version python*-setuptools. In my particular case, it doesn't help
without further modifications, because the package isn't buildable on
Squeeze anyway (there's no dh sphinxdoc I think).
3) Some combination of the B-D versioning and #2.
4) Or something else (e.g. specify a minimum version in .use_setuptools() that
gets satisfied on Squeeze.
Scott and Jakub both expressed support for #3, which isn't difficult. I'm
happy to do that for my own packages, but I think it's worthwhile making sure
everyone's on the same page.
Cheers,
-Barry
|
| |
 |
|
 |
|
|
|
|
|
On Fri, 27 Jan 2012 01:02:42 -0500, Scott Kitterman <...@kitterman.com
...
...
I think my recommendation would be closer to make it die with fire.
Scott K
--
To UNSUBSCRIBE, email to debi...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact list...@lists.debian.org
Archive: http://lists.debian.org/3649962.jD46rt4tKR@scott-latitude-e6320
|
|
|
|
|
|
|
|
|
On Fri, 27 Jan 2012 11:22:52 +0100, Jakub Wilk <...@debian.org
* Scott Kitterman <...@kitterman.com
A witch! A witch! Burn her! Burn her! (Together with her younger sister,
ez_setup.)
--
Jakub Wilk
--
To UNSUBSCRIBE, email to debi...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact list...@lists.debian.org
Archive:
|
|
|
|
|
|
|
|
|
On Fri, 27 Jan 2012 11:28:05 +0100, Piotr Ożarowski <...@debian.org
[Jakub Wilk, 2012-01-27]
+1 :-)
--
Piotr Ożarowski Debian GNU/Linux Developer
http://www.ozarowski.pl http://www.griffith.cc http://www.debian.org
GPG Fingerprint: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645
--
To UNSUBSCRIBE, email to debi...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact list...@lists.debian.org
Archive:
|
|
|
|
|
|
|
|
|
On Fri, 27 Jan 2012 12:22:38 +0100, Piotr Ożarowski <...@debian.org
[Barry Warsaw, 2012-01-26]
import sys
try:
import distribute # import setuptools?
except ImportError:
if '--download-distribute' in sys.argv:
import distribute_setup
distribute_setup.use_setuptools()
else:
print exit(1)
--
Piotr Ożarowski Debian GNU/Linux Developer
http://www.ozarowski.pl http://www.griffith.cc http://www.debian.org
GPG Fingerprint: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645
--
To UNSUBSCRIBE, email to debi...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact list...@lists.debian.org
Archive:
|
|
|
|
|
|
|
|
|
On Fri, 27 Jan 2012 13:14:10 +0100, Brian Sutherland <...@vanguardistas.net
+lots for just killing it completely, but as you say, that's
not-negotiable.
+1 for setting a minimum version upstream. That keeps divergence between
upstream and Debian minimal. Hopefully more python developers pick that
up and Debian packagers will have an easier ride.
Extra bonus points for getting PJE to change the DEFAULT_VERSION in
setuptools trunk to something OK for most major distributions;)
--
Brian Sutherland
--
To UNSUBSCRIBE, email to debi...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact list...@lists.debian.org
Archive:
|
|
|
|
|
|
|
|
|
On Fri, 27 Jan 2012 08:36:40 -0500, Barry Warsaw <...@python.org
Here's a thought:
What if we proposed a hook to get DEFAULT_VERSION from a file or environment
variable? Then at least on Debian systems we could provide that file in our
python-setuptools package, or set the envar in our d/rules files? I'd
probably prefer the former since it would allow us to specify the default
version for the majority of Python packages. The two aren't mutually
exclusive, but I'm not sure both would be useful.
What would that file name be?
Is this just adding more nonsense to insanity? If it would be useful, I'd be
happy to pursue it in upstream.
-Barry
|
|
|
|
|
|
|
|
|
On Fri, 27 Jan 2012 15:38:28 +0100, Brian Sutherland <...@vanguardistas.net
I'm not sure it's more useful than just setting DEFAULT_VERSION to a
very old version. It's certainly more complex.
--
Brian Sutherland
--
To UNSUBSCRIBE, email to debi...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact list...@lists.debian.org
Archive:
|
|
|
|
|
|
|
|
|
On Fri, 27 Jan 2012 11:16:02 -0500, Barry Warsaw <...@python.org
Yes, but it would allow us to "solve" this once, globally, rather than
patching every upstream package that uses distribute_setup.py. We can't
control what upstreams do, but if we could make it easier to adhere to our own
policies without patching upstream, all the better.
-Barry
|
|
|
|
|
|
|
|
|
On Fri, 27 Jan 2012 17:43:58 +0100, Brian Sutherland <...@vanguardistas.net
Hmm, I thought my solution would ""solve" this problem once globally" :)
But I realize that I was quite imprecise in my comment about DEFAULT_VERSION,
I think use_setuptools should do this kind of thing:
DEFAULT_VERSION="0.6c11"
MIN_ACCEPTABLE_VERSION='0.6b1' # very very old version with
# hopefully not too many bugx
def use_setuptools(version=MIN_ACCEPTABLE_VERSION):
if setuptools_installed:
if installed_setuptools_version < version:
download(DEFAULT_VERSION)
else:
download(DEFAULT_VERSION)
Currently MIN_ACCEPTABLE_VERSION=DEFAULT_VERSION according to
http://peak.telecommunity.com/dist/ez_setup.py.
As I understand it, your suggestion is to allow Debian systems to
override MIN_ACCEPTABLE_VERSION. I don't think that's necessary to
"solve" the problem if the default for MIN_ACCEPTABLE_VERSION is
sufficiently old.
--
Brian Sutherland
--
To UNSUBSCRIBE, email to debi...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact list...@lists.debian.org
Archive:
|
|
|
|
|
|
|
|
|
On Mon, 30 Jan 2012 20:21:38 -0500, Barry Warsaw <...@python.org
Hi Brian. What I meant by "globally" was to avoid having to patch any
distribute_setup.py or even setup.py in every upstream package itself.
If use_setuptools() could consult some file or environment variable that was
within the domain of the operating system, that would avoid having to patch
every package that uses distribute_setup.py (or ez_setup.py).
Cheers,
-Barry
--
To UNSUBSCRIBE, email to debi...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact list...@lists.debian.org
Archive:
|
|
|
|
|
|
|
|
|
On Tue, 31 Jan 2012 13:06:50 +0100, Brian Sutherland <...@vanguardistas.net
I see, sorry I was being quite thick.
With my proposal you'd need to wait for all the upstreams to update
their ez_setup.py/distribute_setup.py. I'm sure they don't do that
frequently.
That looks very difficult, distribute_setup.py is very self-contained.
It would probably need to make this:
pkg_resources.require("distribute
even when it's not, but then only when you're calling setup.py. I
suppose dh_python2 can set an environment variable and pkg_resources can
be patched to tell lies when that environment variable is set.
My gosh but that's ugly...
--
Brian Sutherland
--
To UNSUBSCRIBE, email to debi...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact list...@lists.debian.org
Archive:
|
|
|
|
|
|
|
|
|
On Fri, 27 Jan 2012 15:07:10 +0100, Julien Cristau <...@logilab.fr
I think a build system downloading random stuff from random places on
the internet is just as insane upstream as in debian...
Cheers,
Julien
--
Julien Cristau <...@logilab.frLogilab http://www.logilab.fr/
Informatique scientifique & gestion de connaissances
--
To UNSUBSCRIBE, email to debi...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact list...@lists.debian.org
Archive:
|
|
|
|
|
|
|
|
|
On Fri, 27 Jan 2012 11:14:18 -0500, Barry Warsaw <...@python.org
For upstream development, it's handy. I like that `python setup.py test`, or
virtualenv usage will ensure that all your setup.py dependencies are
satisfied, downloading from Cheeseshop if necessary (with overrides to disable
this of course).
But I definitely agree that *building* that package for Debian should never
download anything other than from the official archives. If the archive can't
satisfy a dependency, then it should never download from Cheeseshop.
-Barry
|
|
|
|
|
|
|
|
|
On Fri, 27 Jan 2012 17:20:36 +0100, Julien Cristau <...@logilab.fr
I don't doubt it's handy. I just think it's insane.
Cheers,
Julien
--
Julien Cristau <...@logilab.frLogilab http://www.logilab.fr/
Informatique scientifique & gestion de connaissances
--
To UNSUBSCRIBE, email to debi...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact list...@lists.debian.org
Archive:
|
|
|
|
|
|
|