Re: to distribute_setup() or not, that is the question

[Brian Sutherland]

On Mon, Jan 30, 2012 at 08:21:38PM -0500, Barry Warsaw wrote:
> On Jan 27, 2012, at 05:43 PM, Brian Sutherland wrote:
> 
> >On Fri, Jan 27, 2012 at 11:16:02AM -0500, Barry Warsaw wrote:
> >> On Jan 27, 2012, at 03:38 PM, Brian Sutherland wrote:
> >> 
> >> >On Fri, Jan 27, 2012 at 08:36:40AM -0500, Barry Warsaw wrote:
> >> >> 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.
> >> >
> >> >I'm not sure it's more useful than just setting DEFAULT_VERSION to a
> >> >very old version. It's certainly more complex.
> >> 
> >> 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.
> >
> >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.
> 
> 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.

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.

> 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).

That looks very difficult, distribute_setup.py is very self-contained.
It would probably need to make this:

pkg_resources.require("distribute>="+version) == True

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 debian-python-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120131120650.GA73049@Brians-MacBook-Air.local

Request for pyramid application packaging recommendations

[Olivier Sallou]

Hi,
I plan to create an application using pyramid application server.

Is there any constraint/recommandation to package my application after
that as a Debian package?

My concern is, after a very quick test with Pyramid, that Pyramid adds
some eggs etc... in my application directory (such as
zope.sqlalchemy-0.6.1-py2.7.egg, ...).  I think I could remove those
files in "source" package and add symlinks to Debian packaged files, but
I'd like to know if other caveats may occur.

I am not a pyramid expert, and if pyramid is an issue to package my web
application in Debian, I may switch to something else...

Thanks

Olivier

-- 


gpg key id: 4096R/326D8438  (pgp.mit.edu)
Key fingerprint = 5FB4 6F83 D3B9 5204 6335  D26D 78DC 68DB 326D 8438



-- 
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4f27f148.6050...@irisa.fr

Fwd: Re: Copyright and License status of "transtab"

[Clint Byrum]

Hello. I am working on preparing the 'python-translitcodec' python
module for inclusion in Debian, and I've run into a snag with an
ambiguous license/copyright.

I contacted the author of the python module, and the attributed author
of the directory in question. His reply is below.

Would including the text and headers of said reply in the debian/copyright
file be sufficient to meet the DFSG? I tend to think they would be,
but would appreciate a +1 from those who know better than I.

Thank you!

--- Begin forwarded message from Markus Kuhn ---
From: Markus Kuhn 
To: Clint Byrum 
Cc: Jason Kirtland 
Date: Mon, 30 Jan 2012 03:23:38 -0800
Subject: Re: Copyright and License status of "transtab"

Clint Byrum wrote on 2012-01-30 07:34 UTC:
> My name is Clint, and I'm working on Packaging the python library
> 'translitcodec' for Debian.  In the course of packaging and review, its
> become clear that the license status of one directory of the library
> is ambiguous. Because Debian follows strict guidelines to both avoid
> liability for its developers, and also safeguard user freedom, the
> software won't be accepted without first clarifying this.
> 
> The software in question is available here:
> 
> http://pypi.python.org/pypi/translitcodec/
> 
> Jason, you are the attributed "author". It claims to make use of the
> transtab data provided by you, Dr. Markus Kuhn.
> 
> Can either of you provide documentation of the copyright status and/or
> license granted to this data?

http://www.cl.cam.ac.uk/~mgk25/download/transtab.tar.gz

Should I ever get around to making another transtab release (an old,
unfinished project), I'll try to remember to add the following license
text somewhere:

  Markus Kuhn  -- -mm-dd
  http://www.cl.cam.ac.uk/~mgk25/short-license.html

Executive summary: I promise not to sue you.

Hope this helped ...

Markus

--- End forwarded message ---


-- 
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/1328040264-sup-8...@fewbar.com

Re: New python-qt4 upload to experimental

[Scott Kitterman]

On Sunday, January 29, 2012 12:28:22 AM Scott Kitterman wrote:
> I just uploaded a new python-qt4 revision to experimental (it's arrival will
> be delayed since it has to go through new.
> 
> It is experimental for at least three reasons:
> 
> 1.  It is changed to build with a multiarched Qt as qt4-x11 4.8 in
> experimental is.
> 
> 2.  It builds a new python3-pyqt4-dbus (and dbg) package that needs python3-
> dbus which is only available in experimental at the moment.
> 
> 3.  Because (I believe) it was built against a different Qt version, there
> is a binary incompatible change in it that I know affects python-kde4 and
> may affect other packages.
> 
> My prime suspects for other packages that might be affected are python-
> qscintilla2, python-qwt5-qt4, python-qwt3d-qt4.
> 
> For python-kde4, python -c "import PyKDE4.kdecore" is enough to crash the
> interpreter if the package isn't rebuilt (rebuilding solves it).
> 
> I've written upstream and the only feedback I've gotten back was a reminder
> that ABI on PyQt4 isn't guaranteed.
> 
> I would appreciate it if maintainers for these other packages could take a
> look at what's in experimental and see if their packages are affected.
> 
> I would also appreciate advice on managing this apparent ABI break.

This package, with the changes suggested on debian-python is in Experimental 
now, so please test and provide feedback.

Scott K


-- 
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4429453.8h8l3rU3oW@scott-latitude-e6320