Packaging for Cheeseshop and Debian
Howdy all, I'm writing an application[0] in Python, and am nearly at the point where I want to package it. I need to do so in a way that's useful to me, so that means a Debian package; and useful to anyone using Python, so that means a Python egg available in the Cheeseshop. I have some idea about doing each of those, but no real clues about packaging for both Python's Cheeseshop and a Debian package simultaneously. Where should I start learning about the issues and recommendations? I'd also like to discuss strategies for adding both Debian and Python packaging information when keeping the source in a version-control system, but that should probably be a separate thread. [0]: a small HTTP-accessible helper application -- \ I was stopped by the police for speeding; they said 'Don't you | `\ know the speed limit is 55 miles an hour?' I said 'Yeah I know, | _o__) but I wasn't going to be out that long.' -- Steven Wright | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Packaging for Cheeseshop and Debian
[Please follow URL:http://www.debian.org/MailingLists/#codeofconduct; I don't ask for copies of list messages to be sent to me, so by default please don't.] Raphael Hertzog [EMAIL PROTECTED] writes: On Wed, 14 Mar 2007, Ben Finney wrote: I have some idea about [Debia packages and Python eggs], but no real clues about packaging for both Python's Cheeseshop and a Debian package simultaneously. Where should I start learning about the issues and recommendations? http://wiki.debian.org/DebianPythonFAQ Thanks, that whole page is a good start. I'll consult it often. Check the part concerning eegs. The page says: Adding egg support is only required in some specific cases: when another software uses the python module via an egg and when this egg support is not yet integrated upstream. What is meant by this egg support is not yet integrated upstream? Does this refer to the upstream of the package which depends, or the packages upon which it depends, or both? What would need to be done upstream for this criterion to change? -- \ I bought some powdered water, but I don't know what to add. | `\ -- Steven Wright | _o__) | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Packaging for Cheeseshop and Debian
Raphael Hertzog [EMAIL PROTECTED] writes: On Thu, 15 Mar 2007, Ben Finney wrote: A module that uses eggs to load another module is certainly egg-ready itself. However if the dependency isn't egg-ready, then the package expecting an egg of its dependency will be broken unless we add the egg support to its dependency. What would need to be done upstream for this criterion to change? Switch from distutils to setuptools as shown with the example patch. Thanks, this is clear. -- \ Teach a man to make fire, and he will be warm for a day. Set a | `\ man on fire, and he will be warm for the rest of his life. -- | _o__) John A. Hrastar | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dpkg-gencontrol: warning: unknown substitution variable ${python:Depends}
Raphael Hertzog [EMAIL PROTECTED] writes: On Mon, 19 Mar 2007, Ben Finney wrote: [dpkg-gencontrol complains about unknown substitution variables] dh_pycentral should do it for you... I am using dh_pycentral (as noted in my original message). Or do you mean that, since I'm using dh_pycentral, I should not use dh_gencontrol? what's the content of the package ? If it uses private modules, you should indicate the directory where they are stored as parameter to dh_pycentral. What are private modules? I've never heard that term used in Python. -- \ I think there is a world market for maybe five computers. -- | `\ Thomas Watson, chairman of IBM, 1943 | _o__) | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dpkg-gencontrol: warning: unknown substitution variable ${python:Depends}
Joey Hess [EMAIL PROTECTED] writes:
Ben Finney wrote:
Earlier, I had
Depends: ${python:Depends}, ${shlibs:Depends}, ${misc:Depends}
By removing misc:Depends, you are simply potentially shooting
yourself in the foot.
Fair enough.
and 'dpkg-gencontrol' complained about every one of those.
This is a misfeature of dpkg-gencontrol.
Is 'dh_gencontrol' not useful then? If not, why is it in the
boilerplate created by 'dh_make'? If it is useful, what am I doing
differently that it triggering its misfeatures?
--
\ My theory of evolution is that Darwin was adopted. -- Steven |
`\Wright |
_o__) |
Ben Finney
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dpkg-gencontrol: warning: unknown substitution variable ${python:Depends}
Raphael Hertzog [EMAIL PROTECTED] writes: No I didn't mean that, I just told that dh_pycentral is supposed to create the substvar for you but since it doesn't I need you to answer this question: what's the content of the package ? Pure Python modules, which should be installed to the system site-packages for use by the application. Because the substvar are generated based on what python scripts and python modules are found and where they are located... try running the build with DH_VERBOSE=1 to have more info about what dh_pycentral finds. = ... dh_pycentral List of versions supported according to XS-Python-Version: 2.4 2.5 2.6 100.0 Pyversions field: 2.4- pycentral debhelper gracie debian/gracie Pyversions analysis gives: min=2.4, max= (2.4 2.5 2.6) (grep -s -v python:Versions debian/gracie.substvars; echo python:Versions=\=2.4) debian/gracie.substvars.new mv debian/gracie.substvars.new debian/gracie.substvars dh_link ... = Otherwise please put up the package online somewhere so that we can check what's wrong... You can now get it (across my slow link) with Bazaar: $ bzr branch http://vcs.whitetree.org/bzr/public/gracie/gracie.debian/ Python modules (or extensions) installed in a non-public/standard directory. I haven't specified any special locations for modules; I'm attempting to package a single pure-Python egg, to be installed in the standard location. -- \None can love freedom heartily, but good men; the rest love | `\not freedom, but license. -- John Milton | _o__) | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dpkg-gencontrol: warning: unknown substitution variable ${python:Depends}
Thanks for your suggestions.
Raphael Hertzog [EMAIL PROTECTED] writes:
[package contains only files from the debian/ directory]
That's because you're calling dh_clean -k [at the start of the
'install' rule] which removes what has been installed...
Strange. That's another one placed in debian/rules by 'dh_make'. Under
what circumstances would that be a good thing to do at the start of
the 'install' rule?
Here's a minimal diff of changes:
=== modified file 'debian/control'
...
-Build-Depends: debhelper (= 5.0.38),
+Build-Depends: debhelper (= 5.0.38), docbook-to-man,
Done.
=== modified file 'debian/rules'
...
install: build ${PYVERS:%=install-python%}
dh_testdir
dh_testroot
- dh_clean -k
dh_installdirs
dh_installinit
dh_installpam
I've now moved 'dh_clean -k' to the end of the 'binary' rule.
There's a bashishm in debian/rules:
mv
debian/${PACKAGE_NAME}/usr/lib/python$*/site-packages/${MODULE_NAME}{-${DEB_UPSTREAM_VERSION}-py$*,}.egg-info
That was my optimisation. Fixed now.
But there's more to clean in that package. It's arch: all and should
not be built with all python versions like you're doing. Thus
there's no need to build-depend on python-all-dev but only
python-dev, etc.
I admit to being confused between the recipes for building a Python
package for 'arch: any' and 'arch: all'. You're saying I need to make
this change:
-Build-Depends: python-all-dev
+Build-Depends: python-dev
What other changes do I need to make for an 'arch: all' Python
package?
--
\When you go in for a job interview, I think a good thing to |
`\ ask is if they ever press charges. -- Jack Handey |
_o__) |
Ben Finney
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dpkg-gencontrol: warning: unknown substitution variable ${python:Depends}
Josselin Mouette [EMAIL PROTECTED] writes:
Le lundi 19 mars 2007 à 23:44 +0100, Raphael Hertzog a écrit :
=== modified file 'debian/rules'
--- debian/rules2007-03-19 06:44:04 +
+++ debian/rules2007-03-19 22:37:56 +
@@ -46,7 +46,6 @@
install: build ${PYVERS:%=install-python%}
dh_testdir
dh_testroot
- dh_clean -k
dh_installdirs
dh_installinit
dh_installpam
Nope, dh_clean -k is fine. It's just that installation should start
after calling it, not in the build target.
Isn't that what is shown above (before the patch removes the line)?
After moving 'dh_clean -k' from the 'install' target to the 'binary'
target, the package now builds properly for me (AFAICT). Where are you
saying that line should be moved to?
--
\ Some mornings, it's just not worth chewing through the leather |
`\ straps. -- Emo Philips |
_o__) |
Ben Finney
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Using python-central for pure-Python package (was: dpkg-gencontrol: warning: unknown substitution variable ${python:Depends})
Raphael Hertzog [EMAIL PROTECTED] writes:
On Tue, 20 Mar 2007, Josselin Mouette wrote:
Nope, dh_clean -k is fine. It's just that installation should
start after calling it, not in the build target.
Installation currently happens in install-pythonX.Y which is
called before the install target since it's a dependency. Thus
dh_clean -k removes what's installed.
I see what you're saying now.
Since the package is arch: all the python setup.py call should
simply be placed in the install target and the targets
install-pythonX.Y should be removed.
Part of that target is to rename the generated egg-info directory;
Setuptools creates it as 'foo-N.M-pyX.Y.egg-info', but the
python-central documentation seems to indicate this should be renamed
to 'foo.egg-info':
# install only one Egg dir (without python's version number)
mv
debian/${PACKAGE_NAME}/usr/lib/python$*/site-packages/${MODULE_NAME}-${DEB_UPSTREAM_VERSION}-py$*.egg-info
\
debian/${PACKAGE_NAME}/usr/lib/python$*/site-packages/${MODULE_NAME}.egg-info
How can this be done properly without knowing the exact name
(including Python version) that Setuptools will create?
--
\ The most common of all follies is to believe passionately in |
`\ the palpably not true. It is the chief occupation of mankind. |
_o__) -- Henry L. Mencken |
Ben Finney
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Using python-central for pure-Python package
Raphael Hertzog [EMAIL PROTECTED] writes: Move that to the install target as well and replace $* with the version of the current python (`pyversions -dv`). Thanks. That works, but raises other issues I thought we'd addressed. I'll start a new thread with my questions. -- \ The man who is denied the opportunity of taking decisions of | `\ importance begins to regard as important the decisions he is | _o__) allowed to take. -- C. Northcote Parkinson | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Upstream Makefile, debian/rules, eggs, building and installing
Howdy all, Specific questions in a previous thread have led me to believe that I'm misuderstanding how Debian is supposed to interact with Python packages. The package I'm working on has its own Makefile; this includes a 'build' rule (to build documentation, move executable files around, and build the egg using Setuptools), and an 'install' rule (to install the documentation, executables and egg). The Python source is under a 'src/' subdirectory, and is structured to make development and testing easier. But it contains unit tests and other files that shouldn't be in the resulting installation, hence the 'build' step to copy out the files necessary for installation, and the 'install' step to actually install. The package can be got using Bazaar (across a slow home ADSL link): $ bzr branch http://vcs.whitetree.org/bzr/public/gracie/gracie.devel/ (Note that currently the 'install' rule has been omitted from the Makefile, because I'm still figuring out how these should work together. The questions still stand though.) How should the Debian packaging files interact with this? Examples I've seen for using python-central have the egg being built in the Debian-specific debian/rules targets, but this is clearly duplication if the upstream Makefile already builds an egg. And what about installation -- patch the existing Makefile, or work around it? In normal (non-Debian) usage of Setuptools, a user will generate an egg that is specific to a Python version, and install that; this isn't what's needed by python-central, though. But surely the answer isn't essentially duplication of the build-an-egg step between the upstream Makefile and debian/rules ? These are questions that seem at a level typical for debian-mentors, but it's all specific to Debian packaging of Python packages, so I'm asking here. -- \ Quote me as saying I was mis-quoted. -- Groucho Marx | `\ | _o__) | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Upstream Makefile, debian/rules, eggs, building and installing
Raphael Hertzog [EMAIL PROTECTED] writes: On Wed, 21 Mar 2007, Ben Finney wrote: How should the Debian packaging files interact with this? Examples I've seen for using python-central have the egg being built in the Debian-specific debian/rules targets, but this is clearly duplication if the upstream Makefile already builds an egg. Please be specific... tell us which examples you are referring to. I was referred to URL:http://wiki.debian.org/DebianPythonFAQ which, for python-central, directs me to URL:http://python-modules.alioth.debian.org/python-central_howto.txt. That document lists three example packages: = # package without .so files apt-get source pyparallel # package with .so files apt-get source python-imaging # package with .so files and Egg support apt-get source pyenchant = I looked at 'pyparallel' because I am not packaging extensions, and at 'pyenchant' because I'm packaging with Egg support. We're using a feature of setuptools to provide eggs as unpacked directory trees instead of a single archive. This doesn't duplicate anything and it doesn't mean that we build eggs manually. It does mean that the build step of the existing package, with its 'python ./setup.py --various --options bdist_egg', is discarded, and needs to be done again (in a different way) for the Debian packaging. -- \ Welchen Teil von 'Gestalt' verstehen Sie nicht? [What part of | `\ 'gestalt' don't you understand?] -- Karsten M. Self | _o__) | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Proposed update to the python policy
Pierre Habouzit [EMAIL PROTECTED] writes: On Thu, Mar 22, 2007 at 12:53:27AM +0100, Piotr Ożarowski wrote: How will python-system know to recompile it just for one version and not for all supported ones? Why would you prevent the user to bytecompile your package for every python version he choose to install ? I see the point to avoid archive bloat in not building every binary extension. But locally ? Well, that seems wrong. Really. One reason I can think of: The package fails to build on Python earlier than a particular version, and the user has Python versions older than that concurrently installed. -- \ Don't worry about what anybody else is going to do. The best | `\ way to predict the future is to invent it. -- Alan Kay | _o__) | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: unicode in setup.py file causing RC bug
Scott Kitterman [EMAIL PROTECTED] writes: # -*- encoding: utf-8 -*- Specifically, the directive is 'coding: utf-8' inside those delimiters. (encoding will work also, but only because the parsing of that line allows it.) -- \ Those who will not reason, are bigots, those who cannot, are | `\ fools, and those who dare not, are slaves. -- Lord George | _o__)Gordon Noel Byron | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Python Egg Guidelines across distros
Josselin Mouette [EMAIL PROTECTED] writes: I don't think you need listen to anything the setuptools developers say, as they have close to zero understanding of the packaging issues they create for us. For users stuck in the middle, it would be good if there was a clear statement of exactly what those problems are, that we could refer such setuptools developers to in order that they gain understanding. Where would we find such an explanation? -- \ Programs must be written for people to read, and only | `\ incidentally for machines to execute. -- Abelson Sussman, | _o__) _Structure and Interpretation of Computer Programs_ | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Tool support for private modules
Howdy all, The Debian Python Policy, chapter 3 URL:http://www.debian.org/doc/packaging-manuals/python-policy/ch-programs.html says: 3.1.1 Programs Shipping Private Modules A program using /usr/bin/python as interpreter can come up with private Python modules. These modules should be installed in /usr/share/module, or /usr/lib/module if the modules are architecture-dependent (e.g. extensions). /usr/lib/site-python is deprecated and should no longer be used for this purpose. But the Python distutils and setuptools will install the modules to /usr/lib/site-python/. My 'debian/rules' already has a 'dh_pycentral' line. How can I best conform to the above policy? The dumb way, I imagine, would be to manually install the foles to those specific locations. I'm wondering what tools (e.g. debhelper) support something better, and how to use them to conform to the policy. -- \ God forbid that any book should be banned. The practice is as | `\ indefensible as infanticide. -- Dame Rebecca West | _o__) | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Tool support for private modules
Josselin Mouette [EMAIL PROTECTED] writes: Le lundi 01 octobre 2007 à 14:42 +1000, Ben Finney a écrit : But the Python distutils and setuptools will install the modules to /usr/lib/site-python/. Hrm, they shouldn't. With a default setup, public modules are shipped to /usr/lib/python2.X/site-packages. Yes, my apologies, that's what the tools do. I've no idea why I typed that unrelated path above. My 'debian/rules' already has a 'dh_pycentral' line. That would work if the files were shipped in /usr/lib/python2.X/site-packages. That's where the distutils and setuptools place them by default, yes. I don't know what magic is required to put them elsewhere; that may be part of the answer, if someone can instruct me on how to do it. The trouble is, these are modules that clearly fall under the private modules for the program description in the policy document. I fully agree with the policy that modules intended for internal use by a discrete set of programs should not be installed to the public site-packages directory. How can I use the tools available — distutils, setuptools, debhelper — to install these package-specific modules to a package-specific location, such that all the programs in the package will be able to find them? If, as the location suggests, they are public The location does indeed suggest that, but AFAICT that's only because both distutils and setuptools makes no distinction between modules intended for general use on the system and modules only intended for use by specific programs. If the modules are indeed private, it looks like you need to change the path by hand, and to add it with sys.path.append(/the/path) at the beginning of the binary. Hmm. I am hoping that modify the programs is not a necessary part of this. -- \ He who laughs last, thinks slowest. -- Anonymous | `\ | _o__) | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Tool support for private modules
Bernd Zeimetz [EMAIL PROTECTED] writes: You shoul dupload your work somewhere, teaching you is almost impossible if one can't see what's wrong. I'm not presenting something as wrong. I'm asking for guidance on how to do things right. If the policy recommends that packages be set up a particular way (put package-specific modules in '/usr/share/package/'), but the standard tools behave differently (put all modules by default in '/usr/lib/pythonX.Y/site-packages/'), then there's a step that needs to be taken to get from the default behaviour to the behaviour recommended by policy. I'm asking how to take that step, in a way that isn't brute-force manually hack each package to conform to policy. -- \ Dvorak users of the world flgkd! —Kirsten Chevalier, | `\rec.humor.oracle.d | _o__) | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Tool support for private modules
Josselin Mouette [EMAIL PROTECTED] writes: Le lundi 01 octobre 2007 à 18:37 +1000, Ben Finney a écrit : How can I use the tools available — distutils, setuptools, debhelper — to install these package-specific modules to a package-specific location, such that all the programs in the package will be able to find them? The easiest way, if the modules are relocatable (99% of them are) is to simply move them after installation. Otherwise, you can pass specific arguments to setup.py. That would be, python setup.py install --home=/usr/share/$package --install-purelib=. More information: http://www.python.org/doc/2.4/inst/search-path.html Thanks, this is a useful pointer. I wasn't aware such fine-grained control was available over locations with distutils. (I've certainly never seen any Python author using that control.) Hmm. I am hoping that modify the programs [to add an absolute path to the search path] is not a necessary part of this. If upstream hasn't thought of it, it is. You only need to add one line in the program, before the module is imported. How can upstream anticipate the arbitrary path I pass to './setup.py install --home=/foo/bar' if the path /foo/bar is up to me as a Debian packager? I don't see how any Python program can be written to allow for that without modification every time the /foo/bar changes. -- \ Everything you read in newspapers is absolutely true, except | `\for that rare story of which you happen to have first-hand | _o__) knowledge. -- Erwin Knoll | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Tool support for private modules
Ben Finney [EMAIL PROTECTED] writes: How can I best conform to the [Debian policy for Python modules specific to a single package]? As an example, here's a Python package I'm trying to get packaged for Debian. (I am the upstream author of this one, but I'm interested in a solution that *doesn't* involve significant changes to the upstream code.) URL:http://cheeseshop.python.org/pypi/gracie/ How should I modify 'setup.py' to allow binaries and modules for this package to be installed properly, and have the programs continue to find the modules? How should I construct the command line for 'setup.py' when I create the 'install-python%' target in 'debian/rules' for this package? -- \ Eccles: I just saw the Earth through the clouds! Lew: Did | `\ it look round? Eccles: Yes, but I don't think it saw me. | _o__) -- The Goon Show, _Wings Over Dagenham_ | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Tool support for private modules
(Please preserve attribution lines on quoted material. I don't know who wrote what in the following.) Josselin Mouette [EMAIL PROTECTED] writes: Le lundi 01 octobre 2007 à 23:56 +1000, Ben Finney a écrit : Hmm. I am hoping that modify the programs [to add an absolute path to the search path] is not a necessary part of this. If upstream hasn't thought of it, it is. You only need to add one line in the program, before the module is imported. [...] I don't see how any Python program can be written to allow for that without modification every time the /foo/bar changes. Distutils may be extended to do such a thing, but most of the software I've seen doing it is using automake or changing the files with custom hackery. I'm confused, then. How does this fit with the implication (in the above quoted teset) that upstream should have thought of [changing the location of the modules]? If downstream hackery is required, I don't see what upstream is expected to have done. -- \The most merciful thing in the world... is the inability of | `\ the human mind to correlate all its contents. -- Howard | _o__)Philips Lovecraft | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Tool support for private modules
Bernd, please follow the Debian mailing list code of conduct URL:http://www.debian.org/MailingLists#codeofconduct, in particular by *not* sending personal copies of messages that are also sent to the list. Also, please preserve attribution lines so we can keep track of who wrote what quoted material. Bernd Zeimetz [EMAIL PROTECTED] writes: As an example, here's a Python package I'm trying to get packaged for Debian. [...] URL:http://cheeseshop.python.org/pypi/gracie/ The first thing I'd do here is to patch the ez_ stuff away, together with setuptools. I presume you mean the 'ez_setup.py' module (there's no other 'ez_*' files in that package). ez_... is known to break things badly (like trying to download things on buildds and other really broken things). Setuptools is broken by design imho (see a thread some time ago about this), but it may work. But as I run into trouble with it too often (like missing __init__.py files in random directories), I replace it by distutils. The main reason I use distutils is to assist those people using operating systems that *don't* have good package dependency management, which seems to be the primary target market for setuptools. I also want my package listed properly at the Python Cheeseshop; this is much easier using setuptools than distutils. Since we're not building eggs there's not need for setuptools at all (afaik distutils is able to build eggs now, too - at least the egg info files, which is enough for us). Better to patch those things before getting FTBFS reports form the buildds. Okay. So you're suggesting that I should continue to maintain the setuptools functionality upstream, but patch it out in the Debian package of the same software? I'm also unclear on what you mean by replace it by distutils. What does this mean for a package that already uses setuptools, and will continue to do so upstream? Although I didn't test it, there should be no special thign to do with your setup.py while building a package, python setup.py build/install --root= should do the job (with and without ez_... and setuptools). I'll address this in a separate thread, as it seems I'm not explaining the problem very well. -- \ I bought some powdered water, but I don't know what to add. | `\ -- Steven Wright | _o__) | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Packaging software for Cheeseshop and Debian
Howdy all, In the thread Message-ID: [EMAIL PROTECTED], I asked about package-private modules interacting with setuptools and the Debian Python policy. In retrospect it seems I've got some more fundamental learning to do. I'm not well-versed in Python setuptools or distutils, so I'm probably making many mistakes. I've read the documentation for both, but it's not gelling in my mind. Moreover, I want to package software using setuptools *and* package the same software for Debian. Hence, I run into the issues familiar to most on this list, where the practices of setuptools users and developers clash with the practices of Debian packaging. There doesn't seem to be a great deal of common ground: most of what the setuptools folks recommend is contradicted by what the Debian packagers of Python software recommend. No doubt both have their good and bad arguments for their way of doing things. Meanwhile, I'm stuck trying to learn how to satisfy both, because complying with active conventions and standards is valuable enough to work at. So, I ask for help with this specific package, in the hope that I can learn more general lessons about packaging software for both Python's Cheeseshop and the Debian package system. URL:http://cheeseshop.python.org/pypi/gracie/ URL:http://pypi.python.org/packages/source/g/gracie/gracie-0.2.5.tar.gz When I run './setup.py bdist_egg', I get an egg containing *only* the modules, not the program 'bin/gracied'. What am I doing wrong that is omitting the program from the package? How do I ensure that it will be installed properly from the package? Also, when installing this package, the destination for the modules is the system 'site-packages' directory. These modules, though, are specific to this package and its programs; I'd prefer to have them installed to a different place, but have no idea how to specify that as part of the package metadata or in the 'setup.py'. (I'm *not* talking about the install-time option of *overriding* the default location, but rather to set the location default in the 'setup.py' or other package configuration.) As for packaging this for Debian, what do I need to do in addition to addressing the above? Bear in mind that I intend to continue maintaining this as a setuptools package upstream, for two reasons: I want the benefits of setuptools as already described elsewhere, and I want to know how to do this when I'm *not* the upstream developer. Thanks for reading, and I hope my learning process can be instructive to others. -- \ Once consumers can no longer get free music, they will have to | `\ buy the music in the formats we choose to put out. -- Steve | _o__) Heckler, VP of Sony Music, 2001 | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Tool support for private modules
Ben Finney [EMAIL PROTECTED] writes: The main reason I use distutils is to assist those people using operating systems that *don't* have good package dependency management, which seems to be the primary target market for setuptools. This should, of course, read The main reason I use setuptools … -- \ Pinky, are you pondering what I'm pondering? I think so, | `\Brain, but this time *you* put the trousers on the chimp. -- | _o__)_Pinky and The Brain_ | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Tool support for private modules
Josselin Mouette [EMAIL PROTECTED] writes: Le jeudi 11 octobre 2007 à 10:50 +1000, Ben Finney a écrit : The main reason I use distutils is to assist those people using operating systems that *don't* have good package dependency management, which seems to be the primary target market for setuptools. This is a laudable goal, but not when done at the expense of proper support of operating systems which have one. Indeed. The rest of the message, which you chose not to address this time, asks for help avoiding exactly that trap. Care to answer some of the specific questions in that message and help Python packagers improve their practices? -- \ Remember men, we're fighting for this woman's honour; which is | `\probably more than she ever did. -- Groucho Marx | _o__) | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Packaging software for Cheeseshop and Debian
Ben Finney [EMAIL PROTECTED] writes: In the thread Message-ID: [EMAIL PROTECTED], I asked about package-private modules interacting with setuptools and the Debian Python policy. In retrospect it seems I've got some more fundamental learning to do. I'm not well-versed in Python setuptools or distutils, so I'm probably making many mistakes. I've read the documentation for both, but it's not gelling in my mind. This continues to be the case, in the absence of any informative response. Does no-one have answers to these questions that seem fundamental for packaging Python programs in a way friendly to Debian? -- \ I would rather be exposed to the inconveniences attending too | `\ much liberty than those attending too small a degree of it. | _o__)—Thomas Jefferson | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Packaging software for Cheeseshop and Debian
Sam Clegg [EMAIL PROTECTED] writes:
On Thu, 2007-10-11 at 11:08 +1000, Ben Finney wrote:
So, I ask for help with this specific package, in the hope that I
can learn more general lessons about packaging software for both
Python's Cheeseshop and the Debian package system.
From the looks of your package I don't suppose you're looking for
such a simple answer but the normal way to package executable
scripts would be to specify scripts = ['bin/gracied'] in your
setup,py
Thank you for your reply.
Okay, now that I have that, the program is detected and installed in
the correct location ('/usr/bin/gracied').
Unfortunately, it doesn't run, failing with an ImportError. The
modules are not installed to '/usr/lib/pythonX.Y/...', but only to
'/usr/share/pycentral/gracie/site-packages/gracie/' which isn't on the
system path for Python modules.
A 'find /' for the modules shows that they *only* exist in that
location. Isn't 'python-central' supposed to automatically put them in
the version-specific locations?
I don't know if setuptools or distutils supports packaging private
modules.
Then what is meant by the Python policy speaking of such things?
Is there a particular reason you want to keep it private and not
installed it alongside other python modules?
The modules are not packaged to be a 'python-gracie' system library
module; instead, they're in support of a specific application only. I
was under the impression that the Debian Python steering team wants to
discourage installing application-specific libraries to the
system-library location.
--
\If you continue running Windows, your system may become |
`\ unstable. -- Microsoft, Windows 95 BSOD message |
_o__) |
Ben Finney
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Packaging software for Cheeseshop and Debian
Arthur de Jong [EMAIL PROTECTED] writes: I develop and package webcheck [0] (a python application with private modules). I put all stuff in /usr/share/webcheck and use python-support for compiling the stuff there. Thanks for this response. Unfortunately I've looked at 'webcheck', and it doesn't teach me how to use Python's distutils to achieve this (since, as you note, it doesn't use either of them). My goal is to learn how to package software such that it conforms as much as possible both to Python packaging convention and Debian packaging policy. For the former, that means 'distutils' and, increasingly, 'setuptools'. Hence, packages that don't use either of them aren't what I need. Thank you for your encouragement anyway! -- \ Holy bouncing boiler-plated fits, Batman! -- Robin | `\ | _o__) | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Packaging software for Cheeseshop and Debian
(Bernd, please preserve attribution lines so we know who wrote what quoted material.) Bernd Zeimetz [EMAIL PROTECTED] writes: Thanks for this response. Unfortunately I've looked at 'webcheck', and it doesn't teach me how to use Python's distutils to achieve this (since, as you note, it doesn't use either of them). Instead of looking at packages you should read the distutils documentation. I've read the distutils documentation; it's not very helpful. I've also read the setuptools documentation, which is even less helpful since it assumes a thorough knowledge of distutils. I've also read the Debian Python policy, which doesn't mesh that well with either the distutils or setuptools understanding that I've gained. Presumably it *is* possible to take Python packages that use setuptools, and package them such that they conform with both Python practice and Debian Python policy. Is that incorrect? What packages in Debian can people recommend that use setuptools properly, and are packaged in accordance with the latest Debian Python policy? Or is it simply the case that no packages meet that description? -- \ No wonder I'm all confused; one of my parents was a woman, the | `\ other was a man. -- Ashleigh Brilliant | _o__) | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Packaging software for Cheeseshop and Debian
Sam Clegg [EMAIL PROTECTED] writes: On Wed, 2007-10-24 at 22:10 +1000, Ben Finney wrote: What packages in Debian can people recommend that use setuptools properly, and are packaged in accordance with the latest Debian Python policy? Or is it simply the case that no packages meet that description? I'm sure there are lots of simple packages of modules and/or scripts that use only distutils and conform perfectly to the debian policy. My searching has been in vain so far. I'd love to be proven wrong so that I can learn from an existing package. I'm sure there are people on this list who know more about setuptools who should be able to help you out more. This thread has been active for weeks so far with no such people making themselves known yet. Perhaps there are no people knowledgeable about setuptools on this list? If that's wrong, please chime in! -- \ I was in the first submarine. Instead of a periscope, they had | `\a kaleidoscope. 'We're surrounded.' -- Steven Wright | _o__) | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Python modules not installed correctly with pycentral
Howdy all, In the thread Message-ID: [EMAIL PROTECTED], I attempted to learn more about packaging software such that it conforms both to Python conventions and Debian Python policy. I got some helpful responses, but there seem to be fundamental problems that weren't addressed. I'm asking again now, to try to fix them. The package I'm creating is Gracie: URL:http://cheeseshop.python.org/pypi/gracie/ URL:http://pypi.python.org/packages/source/g/gracie/gracie-0.2.6.tar.gz When I create the Python package independently, with './setup.py bdist_egg', the resulting egg file contains all the modules and programs for the package. The program '/usr/bin/gracied' is able to import the 'gracie' package modules, and it runs successfully. So far so good. I'm packaging it for Debian, and am trying to learn how this is best done. My Bazaar branch for the Debian package can be obtained, and a Debian binary package built: $ bzr branch http://vcs.whitetree.org/bzr/public/gracie/gracie.debian/ $ cd gracie.debian/ $ fakeroot ./debian/rules binary The resulting package contains the program and modules; the modules are in '/usr/share/pycentral/gracie/site-packages/gracie/'. $ cd ../ $ dpkg-deb --contents gracie_0.2.6-1_all.deb [...] drwxr-xr-x root/root 0 2008-01-07 10:59 ./usr/share/pycentral/ drwxr-xr-x root/root 0 2008-01-07 10:59 ./usr/share/pycentral/gracie/ drwxr-xr-x root/root 0 2008-01-07 10:59 ./usr/share/pycentral/gracie/site-packages/ drwxr-xr-x root/root 0 2008-01-07 10:59 ./usr/share/pycentral/gracie/site-packages/gracie/ -rw-r--r-- root/root 1020 2008-01-07 10:58 ./usr/share/pycentral/gracie/site-packages/gracie/__init__.py -rw-r--r-- root/root 1290 2008-01-07 10:58 ./usr/share/pycentral/gracie/site-packages/gracie/authorisation.py -rw-r--r-- root/root 4814 2008-01-07 10:58 ./usr/share/pycentral/gracie/site-packages/gracie/authservice.py -rw-r--r-- root/root 19956 2008-01-07 10:58 ./usr/share/pycentral/gracie/site-packages/gracie/httprequest.py -rw-r--r-- root/root 1610 2008-01-07 10:58 ./usr/share/pycentral/gracie/site-packages/gracie/httpresponse.py -rw-r--r-- root/root 2871 2008-01-07 10:58 ./usr/share/pycentral/gracie/site-packages/gracie/httpserver.py -rw-r--r-- root/root 9740 2008-01-07 10:58 ./usr/share/pycentral/gracie/site-packages/gracie/pagetemplate.py -rw-r--r-- root/root 3235 2008-01-07 10:58 ./usr/share/pycentral/gracie/site-packages/gracie/server.py -rw-r--r-- root/root 1793 2008-01-07 10:58 ./usr/share/pycentral/gracie/site-packages/gracie/session.py drwxr-xr-x root/root 0 2008-01-07 10:59 ./usr/share/pycentral/gracie/site-packages/gracie.egg-info/ [...] The problem apparent when installing that .deb is that after installation the modules *only* exist in that pycentral path; they are never installed to the Python site-packages directory, and so the Python package can't be found by programs that try to import it. $ dpkg --install gracie_0.2.6-1_all.deb Selecting previously deselected package gracie. (Reading database ... 31561 files and directories currently installed.) Unpacking gracie (from .../gracie_0.2.6-1_all.deb) ... Setting up gracie (0.2.6-1) ... Starting Gracie OpenID provider:Traceback (most recent call last): File /usr/bin/gracied, line 18, in ? from gracie.server import become_daemon ImportError: No module named gracie.server invoke-rc.d: initscript gracie, action start failed. dpkg: error processing gracie (--install): subprocess post-installation script returned error exit status 1 Errors were encountered while processing: gracie $ find /usr -name 'server.py' | grep gracie /usr/share/pycentral/gracie/site-packages/gracie/server.py What am I missing? I was under the impression that it was pycentral's task, at install time, to install the modules from '/usr/share/pycentral/gracie/' to the appropriate place for Python to import them. That's not happening though. -- \For fast acting relief, try slowing down. -- Jane Wagner, | `\ via Lily Tomlin | _o__) | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Python modules not installed correctly with pycentral
Christopher Schmidt [EMAIL PROTECTED] writes:
Since it appears you have a *different* postinst, it's possible that
you need something like a #DEBHELPER# snippet in your existing
postinst to allow debhelper to actually put the files in the right
place: when I was missing this in the past, I got similar behavior
(where the postinst in my package was run, but the python-support
postinst wasn't).
The postinst is created automatically by debhelper programs:
= /var/lib/dpkg/info/gracie.postinst
#!/bin/sh
set -e
# Automatically added by dh_installinit
if [ -x /etc/init.d/gracie ]; then
update-rc.d gracie defaults /dev/null
if [ -x `which invoke-rc.d 2/dev/null` ]; then
invoke-rc.d gracie start || exit $?
else
/etc/init.d/gracie start || exit $?
fi
fi
# End automatically added section
# Automatically added by dh_pycentral
if which pycentral /dev/null 21; then
pycentral pkginstall gracie
fi
# End automatically added section
=
Thanks for pointing me to this file. It explains why the 'gracied'
invocation fails during installation: the postinst is trying to start
the program *before* running pycentral to install the modules. That
fails, so the postinst can't continue.
So, with that knowledge, I can look at the 'debian/rules' to see why
it's going in the wrong order. The comments in the postinst are
helpful for this.
The current 'debian/rules' invokes them in this order:
= debian/rules
# ...
.PHONY: install
install: build
dh_testdir
dh_testroot
dh_installdirs
dh_installinit
dh_installpam
python${PYVER} #...
.PHONY: binary-arch
binary-arch: build install
dh_testdir
dh_testroot
dh_installchangelogs
dh_installdocs
dh_installexamples
dh_installman
dh_pycentral
dh_link
# ...
=
With those dependencies, the 'dh_installinit' will run before
'dh_pycentral'.
The only way I can see to fix this is to move one of those commands so
the corrent ordering is achieved in the postinst. Where should I be
moving the rules around to? Should 'dh_installinit' move to the
'binary-arch' rule?
The ordering of commands in that 'debian/rules' is largely unchanged
from what 'dh_make' set up. Should the default placement of
'dh_pycentral' be changed so that 'pycentral' is run early enough for
programs in the package that depend on the installed modules?
--
\ Anyone who believes exponential growth can go on forever in a |
`\ finite world is either a madman or an economist. -- Kenneth |
_o__) Boulding |
Ben Finney
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
debhelper for python-central, problems with prerm/postinst (was: Python modules not installed correctly with pycentral)
(Vincent, please don't send me copies of messages sent to this list. This is spelled out on the mailing-list code of conduct URL:http://www.debian.org/MailingLists/#codeofconduct.) Vincent Bernat [EMAIL PROTECTED] writes: OoO En cette nuit striée d'éclairs du lundi 07 janvier 2008, vers 02:06, Ben Finney [EMAIL PROTECTED] disait: Should the default placement of 'dh_pycentral' be changed so that 'pycentral' is run early enough for programs in the package that depend on the installed modules? Well, if you can change the order for postinst, you will get wrong order in prerm. See: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=386970 http://lists.debian.org/debian-release/2006/10/msg00073.html This is not specific to cdbs in fact, so it applies to you too. Hmm, that's a wrinkle I hadn't thought of. Thank you for showing me that discussion. So, how do Python-language packagers work around this bug currently? -- \ If nature has made any one thing less susceptible than all | `\others of exclusive property, it is the action of the thinking | _o__) power called an idea —Thomas Jefferson | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: debhelper for python-central, problems with prerm/postinst
Vincent Bernat [EMAIL PROTECTED] writes:
On Mon, 07 Jan 2008 18:17:34 +1100, Ben Finney
[EMAIL PROTECTED] wrote:
So, how do Python-language packagers work around this bug
currently?
I don't use dh_installinit and I put the correct snippet in
postinst/prerm by hand, waiting for the bug to be fixed.
When you say by hand, exactly when do you insert the postinst/prerm
snippet? When making the 'debian/foo.{prerm,postinst}' files the first
time? Immediately after building a binary package? Something else?
--
\I was in Las Vegas, at the roulette table, having a furious |
`\ argument over what I considered to be an odd number. -- |
_o__)Steven Wright |
Ben Finney
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Python modules not installed correctly with pycentral
Vincent Bernat [EMAIL PROTECTED] writes: OK. Therefore, if we use pure debhelper : - depends on debhelper (= 5.0.44) That is, Build-Depends: debhelper (= 5.0.44). - set debian/compat to 6 - add a lintian override for this I get no error from 'lintian' for this. Rather, an error from 'linda': E: gracie; DH_COMPAT is greater than the major version of debhelper depended on. What should I be doing about this? - call first dh_pysupport (or dh_pycentral) then dh_installinit Thanks for this explanation, it's a very helpful summary of the discussion. -- \Good morning, Pooh Bear, said Eeyore gloomily. If it is a | `\ good morning, he said. Which I doubt, said he. —A. A. | _o__) Milne, _Winnie-the-Pooh_ | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
debian/rules, moving generated egg-info directory to unversioned name
Howdy all,
In several Debian packages of Python software, I've seen an 'install'
target of 'debian/rules' that contains a command similar to this:
=
install: build
dh_testdir
dh_testroot
dh_installdirs
$(current_python_version) setup.py install
${DEB_PYTHON_INSTALL_ARGS_ALL}
mv
${site_packages_dir}/${MODULE_NAME}-${DEB_UPSTREAM_VERSION}-py${CURRENT_PYTHON_VERSION_NUMBER}.egg-info
\
${site_packages_dir}/${MODULE_NAME}.egg-info
=
This causes, e.g., the egg-info directory 'foo-1.2.3-py2.4.egg-info'
to be moved to 'foo.egg-info'.
Is it a mistake to be dropping the upstream package version string?
Shouldn't this instead be:
=
[...]
mv
${site_packages_dir}/${MODULE_NAME}-${DEB_UPSTREAM_VERSION}-py${CURRENT_PYTHON_VERSION_NUMBER}.egg-info
\
${site_packages_dir}/${MODULE_NAME}-${DEB_UPSTREAM_VERSION}.egg-info
=
resulting in an eventual directory name of 'foo-1.2.3.egg-info', thus
preserving the upstream package version?
--
\If it ain't bust don't fix it is a very sound principle and |
`\ remains so despite the fact that I have slavishly ignored it |
_o__) all my life. —Douglas Adams |
Ben Finney
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [python-odtwriter] package name wrong?
Tristan Seligmann [EMAIL PROTECTED] writes: * Michael Schutte [EMAIL PROTECTED] [2008-02-10 09:17:54 +0100]: On Sat, Feb 09, 2008 at 02:20:26PM +0100, Bernd Zeimetz wrote: So python-docutils-writers-odtwriter would be the right name in theory, but this doesn't make sense, indeed. Does anybody insist on that name? If not, I’m going to update the long description to mention the relationship to python-docutils, which probably would have avoided that bug report in the first place. Personally, I think that package name is ludicrous; python-odtwriter seems fine The name 'python-docutils-odtwriter' seems better to me (I think what makes the above name ludicrous is the utterly redundant '-writers' in the middle). -- \ “A cynic is a man who, when he smells flowers, looks around for | `\ a coffin.” —Henry L. Mencken | _o__) | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian 4.1 and Python 2.5
Adrián Ribao Martínez [EMAIL PROTECTED] writes: El Miércoles, 13 de Febrero de 2008, Steffen Mutter escribió: Adrián Ribao Martínez schrieb: Hello, I'd like to know if Python 2.5 will be the default version of python in Debian 4.1. So I supposse it is already in testing isn't it? No need to suppose, you can search the package metadata URL:http://www.debian.org/distrib/packages#search_packages. Hmm. Unfortunately, a search for packages with name 'python' gives: Your search was too wide so we will only display exact matches. At least 100 results have been omitted and will not be displayed. Please consider using a longer keyword or more keywords. which isn't very helpful, since someone searching for 'python' won't know how to refine the search further. Also, why prevent the user from seeing lots of search results? -- \ Everything you read in newspapers is absolutely true, except | `\for that rare story of which you happen to have first-hand | _o__) knowledge. -- Erwin Knoll | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Current distutils-sig discussion on package management
Howdy all, The Python distutils-sig group is currently discussing the topic of package management, how setuptools interacts with package managers, and what changes are desirable as a result. URL:http://mid.gmane.org/[EMAIL PROTECTED] Message-ID: [EMAIL PROTECTED] From: Phillip J. Eby [EMAIL PROTECTED] URL:http://mid.gmane.org/[EMAIL PROTECTED] Message-ID: [EMAIL PROTECTED] From: Guido van Rossum [EMAIL PROTECTED] URL:http://mid.gmane.org/[EMAIL PROTECTED] Message-ID: [EMAIL PROTECTED] From: Jeff Rush [EMAIL PROTECTED] I urge anyone who's had problems getting Python setuptools and Debian package management working together, to join this discussion so that your issues can be considered in whatever changes ensue. -- \ If we don't believe in freedom of expression for people we | `\ despise, we don't believe in it at all. -- Noam Chomsky | _o__) | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Debian Python developers, make your packaging concerns known (was: Current distutils-sig discussion on package management)
Ben Finney [EMAIL PROTECTED] writes: The Python distutils-sig group is currently discussing the topic of package management, how setuptools interacts with package managers, and what changes are desirable as a result. URL:http://mid.gmane.org/[EMAIL PROTECTED] [...] I urge anyone who's had problems getting Python setuptools and Debian package management working together, to join this discussion so that your issues can be considered in whatever changes ensue. To reiterate: This discussion is happening *now*. If ever you have looked at Python packaging (e.g. distutils or setuptools) and said no, *no*, NO!, then this is the time to get involved so that changes can be made for the better. I have no knowledge of *what* the problems are; I only know that there are people in this group who persistently complain about how Python's current packaging practices are broken with respect to Debian packaging. URL:http://mid.gmane.org/[EMAIL PROTECTED] Message-ID: [EMAIL PROTECTED] From: Guido van Rossum [EMAIL PROTECTED] Date: Wed, 19 Mar 2008 14:23:26 -0700 I'm back at Google and *really* busy for another week or so, so I'll have to postpone the rest of this discussion for a while. If other people want to chime in please do so; if this is just a dialog between Phillip and me I might incorrectly assume that nobody besides Phillip really cares. Please, if you have suggestions for what Python packaging could do better, and improve Debian packaging of Python packages, *now* is the time to join that discussion over at the distutils-sig. -- \ “I was gratified to be able to answer promptly and I did. I | `\ said I didn't know.” —Mark Twain, _Life on the Mississippi_ | _o__) | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian Python developers, make your packaging concerns known
Matthias Klose [EMAIL PROTECTED] writes: Ben Finney writes: I have no knowledge of *what* the problems are; I only know that there are people in this group who persistently complain about how Python's current packaging practices are broken with respect to Debian packaging. the discussion on the python-dev and distutils-sig ML's is about packaging of eggs, not Python packaging in general. It's moved on from that. An explicit request to discuss Python packaging has been made (in a new thread started today). URL:http://mid.gname.org/[EMAIL PROTECTED] Message-ID: [EMAIL PROTECTED] From: Jeff Rush [EMAIL PROTECTED] Subject: Request for Input re Packaging Date: Wed, 19 Mar 2008 18:17:54 -0500 In researching the state of packaging, I've been reading the archives and all the bug reports filed against distutils. I'd like though to get some examples of particularly troublesome uses of setup.py, to pull together and propose some changes to make their use case a bit easier. So far such cases I've been made aware of are Twisted, numpy and SciPy. If you know of a tough case where the developer had to jump through hoops to make it work, please point me to it. I'd also like to get suggestions of improvements to PyPI, which I've not seen much discussion about. [...] Again: if *anyone* involved with packaging Python modules or applications for Debian has *any* suggestions for changes that would make things easier in Debian, please join that thread and contribute. Now is the time. -- \ “Philosophy is questions that may never be answered. Religion | `\ is answers that may never be questioned.” —anonymous | _o__) | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian Python developers, make your packaging concerns known
Ben Finney [EMAIL PROTECTED] writes: An explicit request to discuss Python packaging has been made (in a new thread started today). URL:http://mid.gname.org/[EMAIL PROTECTED] Sorry, URL:http://mid.gmane.org/[EMAIL PROTECTED] is the correct one. -- \ Well, my brother says Hello. So, hooray for speech therapy. | `\-- Emo Philips | _o__) | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: handling /usr/local/lib/python2.x/site-packages in sys.path
Barry Warsaw [EMAIL PROTECTED] writes: On Mar 11, 2008, at 6:36 PM, Floris Bruynooghe wrote: The sysadmin should never install things into /usr/ directly, /usr/local/ is their playground. This is Debian policy (which is fine), but I don't think all distros agree. Those distros that claim to adhere to the FHS agree. /usr is shareable, read-only data. That means that /usr should be shareable between various FHS-compliant hosts and must not be written to. Any information that is host-specific or varies with time is stored elsewhere. URL:http://www.pathname.com/fhs/pub/fhs-2.3.html#THEUSRHIERARCHY The /usr/local hierarchy is for use by the system administrator when installing software locally. It needs to be safe from being overwritten when the system software is updated. It may be used for programs and data that are shareable amongst a group of hosts, but not found in /usr. URL:http://www.pathname.com/fhs/pub/fhs-2.3.html#USRLOCALLOCALHIERARCHY -- \ “The cost of education is trivial compared to the cost of | `\ ignorance.” —Thomas Jefferson | _o__) | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Proposed new package, bugs-everywhere_0.0.193-1.1
Howdy all, I'm putting together a new Debian package, 'bugs-everywhere', in anticipation of having someone sponsor it into Debian. I'd like to get feedback on my packaging efforts before seeking a sponsor, as I'm still rather green at packaging Python applications. (I'm also seeking Alioth hosting for the project, but encountering technical difficulties unrelated to the package.) The source package can be had here: URL:http://www.cyber.com.au/~benf/bzr/bugs-everywhere/build-area/bugs-everywhere_0.0.193-1.1.dsc URL:http://www.cyber.com.au/~benf/bzr/bugs-everywhere/build-area/bugs-everywhere_0.0.193.orig.tar.gz URL:http://www.cyber.com.au/~benf/bzr/bugs-everywhere/build-area/bugs-everywhere_0.0.193-1.1.diff.gz Possibly also of interest: URL:http://www.cyber.com.au/~benf/bzr/bugs-everywhere/build-area/bugs-everywhere_0.0.193-1.1_i386.changes The package currently passes Lintian v1.23.46 with no errors, and only a warning about the package version number. I'd appreciate any feedback from those more experienced with Debian packaging in general and Python packaging in particular. -- \When you go in for a job interview, I think a good thing to | `\ ask is if they ever press charges. -- Jack Handey | _o__) | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Check license and copyright of files in entire tree
Mike Hommey [EMAIL PROTECTED] writes: On Mon, Apr 21, 2008 at 11:27:18PM +1000, Ben Finney wrote: $ licensecheck --recursive --copyright . Just don't forget that it will skip a lot of file types by default. Thanks. From the program source, the default regex for files to check is: my $default_check_regex = '\.(c(c|pp)?|h(h|pp)?|p(l|m)|sh|php|py|rb|java|el)$'; The '--check=foobarbazregex' option overrides this. -- \“Holy knit one purl two, Batman!” —Robin | `\ | _o__) | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: debhelper 7 and python-central
Floris Bruynooghe [EMAIL PROTECTED] writes: On Mon, May 19, 2008 at 12:49:11PM +0200, Josselin Mouette wrote: Python-central links modules at their original places while python-support puts them in /var/lib to follow the FHS. /var/lib : Variable state information [...] State information is data that programs modify while they run, and that pertains to one specific host. [2] Agreed. Complied-one-time-on-install Python library code is not variable state information; rather, it is an unchanging (modulo package-system changes) part of the system, so belongs in /usr somewhere. -- \ It seems intuitively obvious to me, which means that it might | `\be wrong. -- Chris Torek | _o__) | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: debhelper 7 and python-central
Pierre Habouzit [EMAIL PROTECTED] writes: On Mon, May 19, 2008 at 11:20:10PM +, Ben Finney wrote: Floris Bruynooghe [EMAIL PROTECTED] writes: /var/lib : Variable state information [...] State information is data that programs modify while they run, and that pertains to one specific host. [2] Agreed. Complied-one-time-on-install Python library code is not variable state information; rather, it is an unchanging (modulo package-system changes) part of the system, so belongs in /usr somewhere. pysupport puts a farmlink in /var/lib so that .pyc files that are /var material are in /var/lib. What makes you think 'foo.pyc' is /var material? It's compiled once when the package is installed, and shouldn't change thereafter. That isn't data that programs modify while they run, it's the binary form of the program itself. The .py files live in /usr/share. That's fine. Note that the real issue here for real is that python isn't capable of using an alternate shadow path hierarchy to store .pyc files like e.g. fontconfig does. That's why pycentral/pysupport have to do really scabrous things in the first place. Agreed, and thank you for a wonderful use of the word scabrous :-) -- \If you continue running Windows, your system may become | `\ unstable. -- Microsoft, Windows 95 BSOD message | _o__) | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: debhelper 7 and python-central
Pierre Habouzit [EMAIL PROTECTED] writes: On Tue, May 20, 2008 at 10:59:05AM +, Ben Finney wrote: What makes you think 'foo.pyc' is /var material? Oh yes that seems obvious to me. In fact, I'd say it should be /var/cache material because: + it's not mandatory to have it, python works fine without .pyc, just (way) slower (which makes it /something/*cache* material per se). It works fine without it only in the sense that it has to re-generate it before the program can run. Much like any compiled form of a program. + it can be regenerated any time when a python version change (so that we can gain new optimizations in how bytecode is built e.g.) which makes it rather /var material rather than /usr. This property still makes it change only when the packaging system upgrades or installs software. If it only changes at that time, it still seems more appropriate for /usr/ than /var/. -- \ My mother was like a sister to me, only we didn't have sex | `\ quite so often. -- Emo Philips | _o__) | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
FHS location for Python libraries as locally-compiled bytecode (was: debhelper 7 and python-central)
Josselin Mouette [EMAIL PROTECTED] writes: The python-central approach puts in the same directories files managed by dpkg and files managed by python-central, which means they cannot be sorted out easily, and if you run in a bug like #409390 or #480741, you’re hosed. If anything ever gets wrong with python-support, all you need to do is to run update-python-modules -f and the /var/lib/python-support hierarchy will be entirely regenerated. I find this a convincing argument for separating the source and compiled versions (and thank you, I hadn't thought of this). I don't see that it leads to storing the compiled programs to live under /var/, rather than /usr/ which to my mind is more appropriate for compiled versions of programs installed by the package manager, which don't change except through explicit sysadmin action to change them. As for the FHS argument, I don’t feel strongly for putting these files in /var/lib, it just seemed like the most obvious location as this is data that can be regenerated at any time. It can be changed very easily if there is consensus that another place is better. FHS 2.3 §4 allows for: /usr/libqual : Alternate format libraries (optional) Purpose /usr/libqual performs the same role as /usr/lib for an alternate binary format, except that the symbolic links /usr/libqual/sendmail and /usr/libqual/X11 are not required. [26] Python source code versus compiled Python bytecode certainly qualifies as an alternative binary format, so this seems the most applicable section of the FHS. Would '/usr/libcompiled/' or '/usr/libbytecode/' be an appropriate hierarchy to place locally-compiled bytecode for package-installed software? What I do feel strongly for, is putting them in a directory that remains separate from /usr/lib/python2.X. Thanks for your convincing argument, I'm now in support of this much. -- \ When I was little, my grandfather used to make me stand in a | `\ closet for five minutes without moving. He said it was elevator | _o__) practice. -- Steven Wright | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
dh_pycentral and dh_pysupport clash
Howdy all, I'm having a conflict between 'dh_pycentral' and 'dh_pysupport' that I can't see how to resolve. Case study: 'python-minimock' URL:http://ftp.debian.org/debian/pool/main/p/python-minimock/python-minimock_0.8-4.dsc Currently (in 0.8-4) the 'debian/rules' has the following targets of interest: = .PHONY: install install: build dh --with python_central install --before pysupport dh --with python_central install --after pysupport .PHONY: binary-indep binary-indep: build install dh --with python_central binary-indep --before pysupport dh --with python_central binary-indep --after pysupport = This builds, but *only* with both of 'python-central' and 'python-support' installed. However, the package shouldn't need 'python-central' at all; it wants to avoid it altogether. When I test the package with 'pdebuild' in a 'sid' pbuilder, it fails: = $ pdebuild ../build-area/python-minimock_0.8-4.dsc […] fakeroot debian/rules binary dh build dh --with python_central install --before pysupport dh: command specification pysupport does not match any command in the sequence make: *** [install] Error 1 dpkg-buildpackage: failure: fakeroot debian/rules binary gave error exit status 2 pbuilder: Failed autobuilding of package - Aborting with an error - unmounting dev/pts filesystem - unmounting proc filesystem - cleaning the build env - removing directory /var/cache/pbuilder/build//7246 and its subdirectories = This is presumably because 'python-support' is not installed, as is correct for the package dependencies. Ideally, I'd only need those rules to say: = .PHONY: install install: build dh --with python_central install .PHONY: binary-indep binary-indep: build install dh --with python_central binary-indep = This does, in fact, cause the 'pdebuild' to succeed. However, if 'python-support' *is* installed, then this causes *both* of 'dh_pysupport' and 'dh_pycentral' to run, and the resulting package fails 'lintian': = $ bzr-buildpackage […] dh --with python_central install […] running install_scripts […] dh_pysupport --with python_central Compatibility mode: using detected XS-Python-Version. dh_pycentral --with python_central […] $ lintian -I ../build-area/python-minimock_0.8-4_powerpc.changes E: python-minimock: malformed-python-version 2.4, 2.5, all = Why is 'dh --with python_central install' running 'dh_pysupport' at all? How can I stop that and only use 'dh_pycentral' as requested, without breaking the package build in the absence of 'python-support'? -- \ “What I have to do is see, at any rate, that I do not lend | `\ myself to the wrong which I condemn.” —Henry Thoreau, _Civil | _o__)Disobedience_ | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dh_pycentral and dh_pysupport clash
Ben Finney [EMAIL PROTECTED] writes: = .PHONY: install install: build dh --with python_central install --before pysupport dh --with python_central install --after pysupport .PHONY: binary-indep binary-indep: build install dh --with python_central binary-indep --before pysupport dh --with python_central binary-indep --after pysupport = This builds, but *only* with both of 'python-central' and 'python-support' installed. However, the package shouldn't need 'python-central' at all; it wants to avoid it altogether. This should of course say: However, the package shouldn't need 'python-support' at all; it wants to avoid it altogether. -- \“Always code as if the guy who ends up maintaining your code | `\ will be a violent psychopath who knows where you live.” —John | _o__) F. Woods | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
FHS location for locally-compiled bytecode (was: FHS location for Python libraries as locally-compiled bytecode)
A little while ago on debian-python, we discussed the location of system files that are executable bytecode, created by package management tools at install time, and how to comply with th FHS. Ben Finney [EMAIL PROTECTED] writes: Josselin Mouette [EMAIL PROTECTED] writes: As for the FHS argument, I don’t feel strongly for putting [compiled Python bytecode] files in /var/lib, it just seemed like the most obvious location as this is data that can be regenerated at any time. It can be changed very easily if there is consensus that another place is better. FHS 2.3 §4 allows for: /usr/libqual : Alternate format libraries (optional) Purpose /usr/libqual performs the same role as /usr/lib for an alternate binary format, except that the symbolic links /usr/libqual/sendmail and /usr/libqual/X11 are not required. [26] Python source code versus compiled Python bytecode certainly qualifies as an alternative binary format, so this seems the most applicable section of the FHS. Would '/usr/libcompiled/' or '/usr/libbytecode/' be an appropriate hierarchy to place locally-compiled bytecode for package-installed software? What I do feel strongly for, is putting them in a directory that remains separate from /usr/lib/python2.X. Thanks for your convincing argument, I'm now in support of this much. This issue applies just as much to other packages with byte-compiled languages (e.g. Elisp bytecode, Java bytecode, etc.) so I'm raising it on debian-devel. I'm strongly of the position that files which should not be changing (except at package-install time) should not be anywhere under '/var', as per the FHS definition of that hierarchy. These files aren't regenerated at any time, instead they are generated once and are then executable bytecode for the installed program that should not change until the package itself changes. Instead, program bytecode compiled on package installation should be under '/usr/libqual' as per FHS 2.3 §4. I agree with Josselin that they don't belong in '/usr/lib' itself. I don't know what a good name for such a compiled program bytecode hierarchy would be; my reading of FHS 2.3 doesn't suggest a good name. Perhaps '/usr/libbytecode'? -- \ “Pinky, are you pondering what I'm pondering?” “I think so, | `\Brain, but why would anyone want to see Snow White and the | _o__) Seven Samurai?” —_Pinky and The Brain_ | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Joining the team with new packages: rope and ropemacs
David Spreen [EMAIL PROTECTED] writes: I am interested in joining the python-modules team with two new packages: rope and ropemacs. (binary packages are called python-rope and python-ropemacs). Thank you! I have looked at these programs with interest, and look forward to having them in Debian. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=467377 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=492931 The package descriptions could be improved, per the guidelines at URL:http://www.debian.org/doc/developers-reference/ch-best-pkging-practices#s-bpp-pkg-synopsis and URL:http://www.debian.org/doc/developers-reference/best-pkging-practices.html#bpp-pkg-desc. The synopses might better be: Python refactoring library Emacs mode for Python refactoring The names Emacs and Python are properly capitalised that way, so should be so in the synopsis. The full descriptions are okay, but are too long (the bullet lists should be paraphrased only to the essentials) and have too much indentation (a single space for bulleted list items is customary). Ropemacs is described as a plugin; this term isn't helpful for Emacs users, where features are implemented via modes or other parts. Is Ropemacs a major mode, or something else? The description should inform the user. I have one question as to the section of the python-ropemacs package. The package provides an emacs mode for Pymacs that is usable in emacs and enables all kinds of IDE-like features. Technically it is a python module (that's why I put it in section: python) but practically it is an emacs mode for python development. What do you think should be the proper section? I think 'devel' is the best section. The over-use of the 'python' section for packages that are merely implemented in Python makes it almost meaningless. -- \ “One seldom discovers a true believer that is worth knowing.” | `\ —Henry L. Mencken | _o__) | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
pyinstall: A New Hope
Howdy all, Ian Bicking, who has been wrestling for some time with Python and packaging issues, has released the tool pyinstall. Have you ever been frustrated by easy_install? Yeah, me neither. But I have heard whispers of discontent. So I'm introducing a new tool for the installation of Python packages: pyinstall. pyinstall is mostly easy_install compatible. That means it finds distributions in the same way as easy_install and it installs packages via setuptools. If you are familiar with easy_install you'll know how to use pyinstall right away. This is not a repudiation of the mechanisms of easy_install, but a refinement. What does it refine? […] URL:http://www.openplans.org/projects/topp-engineering/blog/2008/09/24/pyinstall-a-new-hope/ pyinstall is available in the Cheese Shop URL:http://pypi.python.org/pypi/pyinstall. I'd be interested to know people's experiences with trying it out for packaging Python distributions for Debian. -- \ “I spent all my money on a FAX machine. Now I can only FAX | `\ collect.” —Steven Wright | _o__) | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: pyinstall: A New Hope
Matthias Klose [EMAIL PROTECTED] writes: I'd be interested to know people's experiences with trying it out for packaging Python distributions for Debian. how would it help? a Python distribution is a set of source/binary packages which we do package separately. I think you've fallen prey to the unfortunate terminology differences between Python and operating systems. In Python, a package is what's available for run-time import; it's a namespace available on the system which contains modules ready for import URL:http://docs.python.org/dist/python-terms.html. It's not the same thing as an operating system package. In Python, a distribution is a collection of modules and packages distributed in source or binary form. It's what Debian would call a package URL:http://docs.python.org/dist/distutils-term.html. The pyinstall project is a means for dealing with Python distributions; it is analogous to (and in fact is built upon, and aims to improve on) distutils and setuptools. Sorry for any confusion. -- \ “Reichel's Law: A body on vacation tends to remain on vacation | `\unless acted upon by an outside force.” —Carol Reichel | _o__) | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: help with writing a PEP to ease software distribution
Nicolas Chauvat [EMAIL PROTECTED] writes: Could some people from the Debian-Python team help out with this? […] Would you mind joining the discussion on distutils-sig at http://www.python.org/community/sigs/current/distutils-sig/list/ ? Huge thanks to Josselin Mouette and all others for ongoing effort in the above discussion, presenting clear, positive explanations about exactly what will improve operating system package maintainers's lives when dealing with Python “distributions”. It's a great step forward from hearing only “distutils sucks, and setuptools is worse” to the current ongoing discussion with the Python distutils people on specifically how to improve the situation. Keep it up, folks! -- \ “If I haven't seen as far as others, it is because giants were | `\ standing on my shoulders.” —Hal Abelson | _o__) | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: numpy 1.2.1, switching to git?
Cyril Brulebois k...@debian.org writes: Tristan Seligmann mithra...@mithrandi.net (20/12/2008): My personal preference ordering would probably be: hg, bzr, svn, git git, FD, * bzr, git, hg, FD, svn -- \ “It is difficult to get a man to understand something when his | `\ salary depends upon his not understanding it.” —Upton Sinclair, | _o__) 1935 | Ben Finney -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: numpy 1.2.1, switching to git?
Josselin Mouette j...@debian.org writes: TTBOMK no other VCS is as smooth to operate as subversion *for Debian packages*. Only svn-buildpackage can handle correctly the versioning of the debian/ directory alone. What mis-handlings of a separate ‘debian/’ directory do you know of in the other ‘$VCS-buildpackage’ tools? I've not experienced any mis-handlings of separately-versioned ‘debian/’ with ‘bzr-buildpackage’, but perhaps you know of flaws that I haven't encountered. -- \ “I stayed up all night playing poker with tarot cards. I got a | `\ full house and four people died.” —Steven Wright | _o__) | Ben Finney -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: /usr/local is loved by Debian Python people?
Yaroslav Halchenko deb...@onerussian.com writes: WHY Debian's installation of Python decided to diverge from a common behavior on other distributions: why in a hackish site.py those /usr/local paths are added? I don't know what “hackish” means here. I'll assume you are asking only “why are the ‘/usr/local/foo’ directories in the Python import search path?”. what was the actual use-case they solved? As I understand it, the use case is analogous to the addition of ‘/usr/local/bin’ to the ‘PATH’ environment variable in the default shell profile. isn't it more natural for people installing smth under /usr/local What is ‘smth’? I can't find a package by that name. to adjust their PYTHONPATH env variable and be happy without interfering with other users of the system they share, who do not want to use what is under /usr/local? Again, the idea of ‘/usr/local’ is that it allows the site administrator to install files, libraries, binaries, etc. that will override the OS-installed versions. Adjusting the search path so that those files are found first is necessary to allow that precedence. why should I in my script to take care about infiltration of /usr/local away from sys.path to prevent such interference mentioned above? You would need to ask the system administrator who installed files in that location. Debian, according to Policy, never installs any program or library in ‘/usr/local’; that's the point. why it was hardcoded in the distributed non-configuration site.py, which I can't even configure to prevent such behavior without doing tricks to prevent its automagic 'fix' on every upgrade? Can't the user who wants to avoid what the system administrator has deliberately put in place just modify their own ‘PYTHONPATH’ environment variable? Again, analogous to the situation with shell executable search paths. I would suggest my idiosyncratic solution, which imho would remove some magic and make things transparent and consistent: 1. remove /usr/local from site.py This denies the ability of the system administrator to put local overrides for Python library files in place as simply and consistently as is done for other libraries and executables. 2. for convenience of users who like to run smth with /usr/local in mind, but hate to tune PYTHONPATH What is ‘smth’, and how are its users different in their needs for a consisten search path precedence? Why are such users to be treated differently from those who override the ‘PATH’ variable? is there anyone else who feels similar way? Perhaps, but the case has yet to be made why Python should be treated differently in this regard from so many other parts of the system. -- \ “I must say that I find television very educational. The minute | `\ somebody turns it on, I go to the library and read a book.” | _o__)—Groucho Marx | Ben Finney -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Frozen unstable (was: please test the numpy package)
Ondrej Certik ond...@certik.cz writes: I am unhappy that unstable gets frozen for such a long time, but I understand that with the current setup (e.g. unstable, testing, ..), there is probably no other way. I'm unhappy about it too, but I don't understand it. Where can I find an explanation for the necessity of freezing ‘unstable’ when preparing to release ‘testing’? -- \ “A child of five could understand this. Fetch me a child of | `\ five.” —Groucho Marx | _o__) | Ben Finney -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Compiled bytecode files location (was: Python related changes for unstable/squeeze)
Piotr Ożarowski pi...@debian.org writes:
Sure, pysupport is not perfect. Using /var/ for bytecompiled stuff
is probably the worst of it's bugs, but maintainer is aware of this
and will most probably fix it during the move to
/usr/{share,lib}/py{,3}shared - and I have a reasons to believe that
he'll use this path if you decide to use /usr/lib/py{3,}shared (I'll
convince him, leave it to me ;)
I saw no response to Message-ID: 87skwceynw@benfinney.id.au on
this forum, but would love to be convinced this will be fixed. This is
probably the last remaining issue keeping me with ‘python-central’ for
my packages.
--
\ “He may look like an idiot and talk like an idiot but don't let |
`\ that fool you. He really is an idiot.” —Groucho Marx |
_o__) |
Ben Finney
--
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Compiled bytecode files location
Josselin Mouette j...@debian.org writes: Le mercredi 18 février 2009 à 13:33 +1100, Ben Finney a écrit : I saw no response to Message-ID: 87skwceynw@benfinney.id.au on this forum, but would love to be convinced this will be fixed. This is probably the last remaining issue keeping me with ‘python-central’ for my packages. As I already said, there is no compelling reason to stay in /var, Okay, I didn't see that when I looked back in the list archive. and this can be changed without too much breakage - I just couldn’t do that right before the lenny release. Sure, I was only hoping for discussion at that time, not immediate implementation of changes. I just proposed /usr/lib/pymodules/pythonX.Y instead. Do you think that location is suitable? I think ‘/usr/lib/foo/’ is better than ‘/var/lib/foo/’ for program libraries such as *.py and *.pyc, so to that extent it's a significant improvement. As for which directory names should be used under that hierarchy, I'm currently neutral on most proposed systems I've seen. I'm not educated enough on the issue of separation of these files to have an informed opinion yet. -- \ “Yesterday I saw a subliminal advertising executive for just a | `\ second.” —Steven Wright | _o__) | Ben Finney -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Leaving DPMT?
I see this discussion focussing exclusively on Subversion versus Git; I wish with this message to point out that not all DVCSen are necessarily like Git. To do so, I'll engage in a little advocacy for Bazaar. I hope people can be open to discussion about relative merits of tools. Stephan Peijnik deb...@sp.or.at writes: On Fri, 2009-02-27 at 15:07 +0100, Sandro Tosi wrote: No, what I said was: - I see no need to move to git as a team - I can't afford to download all the git repos for packages I want to modify once This issue is avoidable if the repository is a Bazaar one: Bazaar allows a centralised workflow with its “checkout” feature URL:http://bazaar-vcs.org/CheckoutTutorial URL:http://doc.bazaar-vcs.org/bzr.dev/en/user-guide/index.html#using-checkouts. By default, a checkout causes any commits to the branch to *also* be committed to a remote branch. Optionally, a checkout can be “lightweight” which affords a workflow almost identical to that of Subversion: no initial download of the revision data, all commits are made to the remote repository only URL:http://doc.bazaar-vcs.org/bzr.dev/en/user-guide/index.html#getting-a-lightweight-checkout. Of course, any Bazaar branch (whether a checkout or not) still allows all the DVCS behaviour, getting revision data from the repository as needed. I can to some agree with Sandro here. I'm not a big fan of svn, but for the DPMT repository svn looks like the right choice to me. The big benefit of using svn is that each and every directory in a svn repository can be checked out forming a stand-alone local copy. And this exactly is not possible with other recently more-popular VCS such as Mercurial and git. Bazaar, on the other hand, has a feature for this in newer versions (Bazaar 1.9 and later): you can create a “stacked branch”, allowing a casual contributor to get just that part of the repository URL:http://bazaar-vcs.org/Scenarios/OneOffContribution URL:http://doc.bazaar-vcs.org/bzr.dev/en/user-guide/index.html#using-stacked-branches. With svn it is as simple as checking out one directory (ie. packages/), apply the change and then do a single commit, which will push back all changes. Just like this, except in a DVCS. However, if someone can point out that a 'better' vcs that has this 'every-directory-can-be-a-repository' behaviour, please do so and I would be happy to give that a try. For the “stacked branch” feature, you'll need Bazaar (package name ‘bzr’) version 1.9 or later. Debian ‘unstable' currently only has version 1.5; ‘experimental’ has version 1.12. For “checkout”, including the ‘--lightweight’ option, any version of Bazaar in Debian has this feature. Oh, last but not least, there's the old saying 'never change a running system', which one should really keep in mind when discussing such changes. Definitely. This advocacy is not at all intended as demand for change. -- \ “Don't be afraid of missing opportunities. Behind every failure | `\ is an opportunity somebody wishes they had missed.” —Jane | _o__) Wagner, via Lily Tomlin | Ben Finney -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Leaving DPMT?
Sandro Tosi mo...@debian.org writes: On Sat, Feb 28, 2009 at 01:11, Ben Finney ben+deb...@benfinney.id.au wrote: I see this discussion focussing exclusively on Subversion versus Git; I wish with this message to point out that not all DVCSen are necessarily like Git. WTF?! As Ondrej said just some hours ago: I didn't see that message when I wrote mine. On Fri, Feb 27, 2009 at 16:41, Ondrej Certik ond...@certik.cz wrote: We discussed that in the pust, just find the discussion on this list before. I apologize for opening it again. I don't know what thread that is. Use the right thread to discuss this. Certainly, if someone can point me to the right thread. -- \“I used to work in a fire hydrant factory. You couldn't park | `\ anywhere near the place.” —Steven Wright | _o__) | Ben Finney -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Leaving DPMT?
Ondrej Certik ond...@certik.cz writes: On Fri, Feb 27, 2009 at 4:48 PM, Ben Finney ben+deb...@benfinney.id.au wrote: Certainly, if someone can point me to the right thread. http://www.google.com/search?hl=enq=debian+python+git+svnbtnG=Google+Searchaq=foq= it's the 4th link: http://www.mail-archive.com/debian-python@lists.debian.org/msg04997.html For future reference here's the official link to that message in Debian's own archive: URL:http://lists.debian.org/debian-python/2008/12/msg00083.html which allows easier followup (not least because it shows the Message-Id field). -- \ “Yesterday I saw a subliminal advertising executive for just a | `\ second.” —Steven Wright | _o__) | Ben Finney -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Developer workflow and DVCS (was: Leaving DPMT?)
[re-sending as a followup to an older thread] I see this discussion focussing on Subversion versus Git; I wish with this message to point out that's a false dichotomy, as not all DVCSen are necessarily like Git. To do so, I'll engage in a little advocacy for Bazaar URL:http://bazaar-vcs.org/. I hope people can be open to discussion about relative merits of tools. Stephan Peijnik deb...@sp.or.at writes: On Fri, 2009-02-27 at 15:07 +0100, Sandro Tosi wrote: No, what I said was: - I see no need to move to git as a team - I can't afford to download all the git repos for packages I want to modify once This issue is avoidable if the repository is a Bazaar one: Bazaar allows a centralised workflow with its “checkout” feature URL:http://bazaar-vcs.org/CheckoutTutorial URL:http://doc.bazaar-vcs.org/bzr.dev/en/user-guide/index.html#using-checkouts. By default, a checkout causes any commits to the branch to *also* be committed to a remote branch. Optionally, a checkout can be “lightweight” which affords a workflow almost identical to that of Subversion: no initial download of the revision data, all commits are made to the remote repository only URL:http://doc.bazaar-vcs.org/bzr.dev/en/user-guide/index.html#getting-a-lightweight-checkout. Of course, any Bazaar branch (whether a checkout or not) still allows all the DVCS behaviour, getting revision data from the repository as needed. I can to some agree with Sandro here. I'm not a big fan of svn, but for the DPMT repository svn looks like the right choice to me. The big benefit of using svn is that each and every directory in a svn repository can be checked out forming a stand-alone local copy. And this exactly is not possible with other recently more-popular VCS such as Mercurial and git. Bazaar, on the other hand, has a feature for this in newer versions (Bazaar 1.9 and later): you can create a “stacked branch”, allowing a casual contributor to get just that part of the repository URL:http://bazaar-vcs.org/Scenarios/OneOffContribution URL:http://doc.bazaar-vcs.org/bzr.dev/en/user-guide/index.html#using-stacked-branches. With svn it is as simple as checking out one directory (ie. packages/), apply the change and then do a single commit, which will push back all changes. Just like this, except in a DVCS. However, if someone can point out that a 'better' vcs that has this 'every-directory-can-be-a-repository' behaviour, please do so and I would be happy to give that a try. For the “stacked branch” feature, you'll need Bazaar (package name ‘bzr’) version 1.9 or later. Debian ‘unstable' currently only has version 1.5; ‘experimental’ has version 1.12. For “checkout”, including the ‘--lightweight’ option, any version of Bazaar in Debian has this feature. Oh, last but not least, there's the old saying 'never change a running system', which one should really keep in mind when discussing such changes. Definitely. This advocacy is not at all intended as demand for change. -- \ “Don't be afraid of missing opportunities. Behind every failure | `\ is an opportunity somebody wishes they had missed.” —Jane | _o__) Wagner, via Lily Tomlin | Ben Finney -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Developer workflow and DVCS
Sandro Tosi mo...@debian.org writes: On Sat, Feb 28, 2009 at 02:21, Ben Finney ben+deb...@benfinney.id.au wrote: I see this discussion focussing on Subversion versus Git; I wish with this message to point out that's a false dichotomy, as not all DVCSen are necessarily like Git. Wanna revamp it? Revamp what? I don't know the referent of “it” in your sentence. then here's GvR opinion[1] on DVCSes. That's GvR's opinion specifically in the context of choosing a DVCS for development of Python itself. Since GvR won't (I presume) be using the PMPT or PAPT repositories, his opinion surely counts less than the opinion of those who intend to use these repositories. I don't see why you bring that up. Can you explain the relevance? How does it address the points I've made? -- \ “If we don't believe in freedom of expression for people we | `\ despise, we don't believe in it at all.” —Noam Chomsky, | _o__) 1992-11-25 | Ben Finney -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Developer workflow and DVCS
David Cournapeau courn...@gmail.com writes: On Sat, Feb 28, 2009 at 10:21 AM, Ben Finney ben+deb...@benfinney.id.au wrote: This issue is avoidable if the repository is a Bazaar one: But what does it solve ? The main problem with downloading the whole history is the time taken. The only way to know the relative speed is to measure; in my experience, with a git server, git is as fast as svn to get not too big repositories. The point was, though, that Git requires downloading the whole repository before beginning to work with it; Bazaar does not require that. It of course depends on the speed of the connection, servers, etc... Only experiment can tell. Certainly, experiments would be welcome. Bzr, OTOH, is extremely slow at network operations, much slower than git and/or svn. Subversion requires use of a dedicated server, while Bazaar does not. Thus, many people compare the network speed of Subversion talking to a dedicated server, versus Bazaar using file-level operations only. Naturally, in that comparison, Bazaar will be slower than Subversion. Bazaar *does* allow operations against a Bazaar server, and I've noted it to be significantly faster than Subversion in that mode. Speed is also improving with every Bazaar version, so comparisons rememberd from months ago might be out of date. (again, experiments would be welcome.) Comparisons with Git's network speed at this point would not be valid, since we're talking about something Git *can't do* currently: skip the initial download of the repository. I have never used stacked branches, but are you sure […] No, since I've not used them either. I offer it for anyone wanting to honestly evaluate a DVCS, so that features can be properly compared. I really don't like svn, but in this case, I don't see the point of changing. git-svn has almost no drawback in this case The message I was replying to pointed out significant drawbacks to Git; that was my motivation for posting. -- \ “I have never imputed to Nature a purpose or a goal, or | `\anything that could be understood as anthropomorphic.” —Albert | _o__)Einstein, unsent letter, 1955 | Ben Finney -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Developer workflow and DVCS
Sandro Tosi mo...@debian.org writes: On Sat, Feb 28, 2009 at 23:00, Ben Finney ben+deb...@benfinney.id.au wrote: his opinion surely counts less than the opinion of those who intend to use these repositories. I don't see why you bring that up. You too are not using our repository (because we are so bad that won't adopt bzr and svn is an ugly ugly VCS), so GvR opinion counts as anyone else. This doesn't seem to be a rational conversation any more. Is it some kind of personal attack? I can't actually make much sense out of it. Can you explain the relevance? How does it address the points I've made? Because you only see bzr, while there's much more DVCSes around. Perhaps you've been reading someone else's messages? I was addressing points specific to a comparison between Git, Bazaar, and Subversion, so I don't understand what you're referring to. For me, the discussion (being this particular new branch or the original one, since no advances are made) is closed. Thanks for that. I welcome further discussion on the substance of what's actually been raised, if anyone's interested. -- \ “Progress might have been all right once, but it's gone on too | `\long.” —Ogden Nash | _o__) | Ben Finney -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Piotrek's new preferred Python helper tool - (unfair) decision
Piotr Ożarowski pi...@debian.org writes: PS while converting [a package using python-central to use python-support], remember to add to preinst something like these 3 lines: | if [ $1 = upgrade ] dpkg --compare-versions $2 lt 1.2.3-4; then | pycentral pkgremove python-foo | fi Why does this not happen automatically when the package is upgraded from a version that uses python-central? -- \ “All progress has resulted from people who took unpopular | `\ positions.” —Adlai Stevenson | _o__) | Ben Finney -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Piotrek's new preferred Python helper tool - (unfair) decision
Ondrej Certik ond...@certik.cz writes: why is the decision unfair? You'll have to ask Piotr (the one making the decision, and also the one who chose that subject field), not me. -- \ “Pity the meek, for they shall inherit the earth.” —Donald | `\ Robert Perry Marquis | _o__) | Ben Finney -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Piotrek's new preferred Python helper tool - (unfair) decision
Cyril Brulebois k...@debian.org writes: Piotr Ożarowski pi...@debian.org (03/03/2009): [Cyril Brulebois, 2009-03-03] Piotr Ożarowski pi...@debian.org (02/03/2009): [Ben Finney, 2009-03-02] Why does [removal of links created by ‘python-central’] not happen automatically when the package is upgraded from a version that uses python-central? (I'm not sure whether -central is so buggy that it can't handle removal properly, but I guess it could be.) see #479852 [URL:http://bugs.debian.org/479852] OK. I guess it's the answer Ben was looking for. Yes, that answers my question. For future reference: The above bug report explains that ‘python-central’ causes packages to create symlinks during ‘postinst’, but not remove them during ‘prerm’. -- \ “It was half way to Rivendell when the drugs began to take | `\hold” —Hunter S. Tolkien, _Fear and Loathing in Barad-Dûr_ | _o__) | Ben Finney -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Migrating a package from from python-central: cleaning up (was: Piotrek's new preferred helper tool - (unfair) decision)
Piotr Ożarowski pi...@debian.org writes:
PS while converting [from use of ‘python-central’ to use of
‘python-support’], remember to add to preinst something like these 3
lines:
| if [ $1 = upgrade ] dpkg --compare-versions $2 lt 1.2.3-4; then
| pycentral pkgremove python-foo
| fi
As noted elsewhere, this is to overcome behaviour (discussed in
URL:http://bugs.debian.org/479852) that is the default for
‘dh_pycentral’: “create symlinks on postinst, don't clean up on
prerm”. Because it is the default, this likely plagues a significant
portion of ‘python-central’-based packages already installed out
there.
The approaches suggested in the ‘dh_pycentral(1)’ manpage are:
This can be disabled by setting the environment varibale
DH_PYCENTRAL to a string containing the string noprepare. If the
newer version of a package needs to remove the symlinked files on
upgrade, either the package needs to take care of the removal by
calling pycentrel pkgremove in the new preinst, or leaving a file
/var/lib/pycentral/package.pkgremove and using pycentral 0.6.7
or later for the old package version.
I, like Piotr, am now preparing to migrate my Python packages to use
‘python-support’ (once the new version that stops using ‘/var/lib/’
hits ‘testing’). What is my best approach for preparing to do this? As
I see it, the existing documentation suggests one of:
* Leave the package for now depending on ‘python-central’, set
‘DH_PYCENTRAL = noprepare’ in my existing packages's
‘debian/rules’, then build and upload a new release; or
* Migrate the package immediately to use ‘python-support’, put the
call to ‘pycentral pkgremove foopackage’ in ‘preinst’ as shown
above by Piotr, then build and upload a new release; or
* Migrate the package immediately to use ‘python-support’, create an
empty ‘${DESTDIR}/var/lib/pycentral/foopackage.pkgremove’, then
build and upload a new release; or
* Something else (please specify).
Which of the above is best in general? What reasons would I have for
not doing the same thing to every affected package? How long should I
leave these measures in place before removing all mention of
‘python-central’ from a new release?
--
\ “When I get new information, I change my position. What, sir, |
`\ do you do with new information?” —John Maynard Keynes |
_o__) |
Ben Finney
--
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Migrating a package from from python-central: cleaning up
Piotr Ożarowski pi...@debian.org writes: [Ben Finney, 2009-03-04] As noted elsewhere, this is to overcome behaviour (discussed in URL:http://bugs.debian.org/479852) I'm a little bit busy these days (so I didn't check pycentral's code... yet), but isn't this bug fixed already (probably in 0.6.9 aka 0.6.10)? (I'm confused by that last part. “aka” is “also known as”. Are you saying that 0.6.9 and 0.6.10 are just alternate names for the same version?) I have ‘python-central’ 0.6.11 installed fron ‘testing’, and the manual page for ‘dh_pycentral(1)’ still details the behaviour described in that bug report. -- \ “One time a cop pulled me over for running a stop sign. He | `\said, ‘Didn't you see the stop sign?’ I said, ‘Yeah, but I | _o__)don't believe everything I read.’” —Steven Wright | Ben Finney -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Package names for docutils writers
Michael Schutte mi...@uiae.at writes: The binary package is currently called python-odtwriter; after a discussion in February 2008 [1], I decided to stick with this name. I participated in that discussion, but I find that my position has changed. In the meantime, docutils-writer-manpage entered the archive (Ben Finney). It obviously uses a completely different naming scheme and provides a small rst2man binary package which only contains the frontend. And then there is rst2pdf (Chris Lamb) which does the all-in-one thing in a single eponymous .deb. Since I care about consistency, I’d like to get this sorted out. I applaud this desire for consistency and concur. My personal preference would be “python-docutils-X”: it’s short, reasonably precise and explanatory. How do you think these packages should be called? Any input is welcome, even if it’s just “it doesn’t matter.” Here's my reasoning. I no longer think ‘python-’ is an appropriate prefix for the package name. These packages are primarily components of Docutils, so they are “private” in that they are entirely within the context of Docutils. Since they're not a general-use Python module, the package shouldn't be named like one. So I think the following naming style is appropriate: docutils-reader-foo docutils-reader-bar docutils-transform-wibble docutils-transform-wobble docutils-writer-quux docutils-writer-xyzzy These are components of the Docutils system; and such extensions can be of several distinct purposes (hence “reader”, “transform”, “writer”, etc.) Once all that's said, the rest of the name should be answering the question “A Docutils writer for what?” (likewise for reader, transform, etc.) To my knowledge there are not yet any Docutils components other than writers packaged; but the Docutils design explicitly allows for third-party components of many different kinds (with different purposes, which means they would be best grouped together under similar names). The component is best packaged as a library, separate from the main tool (if any) that uses that library. Either that, or the library package which includes an executable tool should ‘Provides: ’ a virtual package for that tool so that the user can find it by the logical name; this also allows an easier user migration to packaging them separately if that decision is revisited. For the existing components and front-end tools, I would like to see these package names: docutils-writer-odt rst2odt docutils-writer-pdf rst2pdf docutils-writer-manpage rst2man docutils-writer-website rest2web docutils-writer-sphinx sphinx -- \ “Pinky, are you pondering what I'm pondering?” “Um, I think so, | `\Brainie, but why would anyone want to Pierce Brosnan?” —_Pinky | _o__) and The Brain_ | Ben Finney -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Package names for docutils writers
Chris Lamb la...@debian.org writes: Michael Schutte wrote: At the moment it’s really just us three. So, Chris, what do you think? :-) Ah, I like this. We all agreed? So far, yes. Let's give the discussion a week of elapsed time (Michael's original message has the field ‘Date: Wed, 11 Mar 2009 16:55:03 +0100’) to allow other potential contributions a chance to appear. If there are no substantive changes needed by next Wednesday, I think we should call it the consensus and do it. Speaking of which, does this mean the source packages should be renamed? How does on go about doing that, exactly? -- \ “It takes a big man to cry, but it takes a bigger man to laugh | `\at that man.” —Jack Handey | _o__) | Ben Finney -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Package names for docutils writers
Michael Schutte mi...@uiae.at writes: It might make sense to wait a little longer for these uploads: Piotr takes care of python-docutils’ conversion to python-support (from -central) I am waiting for ‘python-support’ 0.90 or later to reach ‘testing’ before doing a similar switch. which means that we’ll have to switch as well. Why is that? Python library packages installed using ‘python-central’ and ‘python-support’ are able to coexist indistinguishably from the point of view of Python programs using them, no? -- \ “To succeed in the world it is not enough to be stupid, you | `\must also be well-mannered.” —Voltaire | _o__) | Ben Finney -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Anticipating the migration: python-support 0.90 in unstable (was: Package names for docutils writers)
Michael Schutte mi...@uiae.at writes: This is how I understand the problem: python-central writes to /usr/lib/python*/site-packages, while python-support uses /var/lib/python-support/python*. Python finds docutils/__init__.py in one directory and doesn’t look for modules starting with “docutils.” anywhere else. Okay, this just makes me more eager to see ‘python-support’ 0.90 or higher (which installs modules to non-‘/var’ directories), so I can begin migrating my packages. What's the prognosis on seeing an upload of that version to ‘unstable’? -- \ “If you ever catch on fire, try to avoid seeing yourself in the | `\mirror, because I bet that's what REALLY throws you into a | _o__) panic.” —Jack Handey | Ben Finney pgpnZlo7rRyu5.pgp Description: PGP signature
Re: Preparing for the new python-support
Josselin Mouette j...@debian.org writes: I have just uploaded version 0.95.0 renamed as 1.0.0: python-support (1.0.0) unstable; urgency=low * Upload to unstable. Thank you! This accounts for 24 remaining bugs that are now RC I don't understand. The BTS shows only 8 open bug reports on ‘python-support’ itself, so I assume you're saying there are now serious-or-higher bugs in other packages. How can we find these bugs; is there a query that reveals them? you can now start hating me. Yay! Emmouette Josselstein is revealed! Let's gather at 11:00 for the URL:http://en.wikipedia.org/wiki/Two_Minutes_Hate! -- \ “On the other hand, you have different fingers.” —Steven Wright | `\ | _o__) | Ben Finney pgpUVsxjE6FxQ.pgp Description: PGP signature
Migrating unmanaged Python library extension from ‘python-central’ to ‘python -support’
Howdy all,
As per bug#523965 URL:http://bugs.debian.org/523965, I'm attempting to
migrate the ‘docutils-manpage-writer’ package from using
‘python-central’ to using ‘python-support’.
The original source currently has no installation method or build
system; I am working with the upstream author to rectify that. In the
meantime, I'm trying to fix the breakage by migrating to
‘python-support’.
Currently (because there is no upstream build system specifically for
this code) the package needs the following rules:
=
PROGRAM_DIR = usr/bin
PROGRAM_NAME = rst2man
WRITERS_DIR = writers
MANPAGE_WRITER_DIR = usr/share/pyshared/docutils/${WRITERS_DIR}
[…]
.PHONY: install
install: build
install -d ${MANPAGE_WRITER_DIR}
install -m 644 writers/manpage.py ${MANPAGE_WRITER_DIR}
install -d ${PROGRAM_DIR}
install -m 755 ${PROGRAM_NAME} ${PROGRAM_DIR}
dh --with python_central install
=
I'm not very familiar with using ‘python-support’, so I'm not clear what
I need to change in these rules. Where do I need to install the library
files for them to be properly discovered by ‘dh_pysupport’?
--
\“Don't fight forces, use them.” —Richard Buckminster Fuller, |
`\ _Shelter_, 1932 |
_o__) |
Ben Finney
--
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Migrating unmanaged Python library extension from ‘python-central’ to ‘python -support’
Cyril Brulebois k...@debian.org writes: Ben Finney ben+deb...@benfinney.id.au (14/04/2009): As per bug#523965 URL:http://bugs.debian.org/523965, I'm attempting to migrate the ‘docutils-manpage-writer’ package from using ‘python-central’ to using ‘python-support’. *-writer-manpage, actually. Yes, thanks for the correction. I'm not very familiar with using ‘python-support’, so I'm not clear what I need to change in these rules. Where do I need to install the library files for them to be properly discovered by ‘dh_pysupport’? Put them into /usr/lib/python*/site-packages, as documented in its manpage? What, though, is ‘python*’ here? Remember, this is specifically for a module that (at present) has no build system upstream; the code is “installed” by manually copying files. I'm attaching a source debdiff with various things that should help you reach some working package. Thanks, I will look at that for some guidance. -- \ “If we have to give up either religion or education, we should | `\ give up education.” —William Jennings Bryan, 1923-01 | _o__) | Ben Finney pgpceEYecX96l.pgp Description: PGP signature
Re: Migrating unmanaged Python library extension from ‘python-central’ to ‘python -support’
Ben Finney ben+deb...@benfinney.id.au writes: Cyril Brulebois k...@debian.org writes: Put them into /usr/lib/python*/site-packages, as documented in its manpage? What, though, is ‘python*’ here? Remember, this is specifically for a module that (at present) has no build system upstream; the code is “installed” by manually copying files. Okay, from your example I see that you mean ‘usr/lib/$(pyversions -d)’. Thanks. -- \ “Friendship is born at that moment when one person says to | `\another, ‘What! You too? I thought I was the only one!’” —C.S. | _o__)Lewis | Ben Finney pgpZ1ms1qQghV.pgp Description: PGP signature
Re: Migrating unmanaged Python library extension from ‘python-central’ to ‘python -support’
Cyril Brulebois k...@debian.org writes: Ben Finney ben+deb...@benfinney.id.au (14/04/2009): I'm not very familiar with using ‘python-support’, so I'm not clear what I need to change in these rules. Where do I need to install the library files for them to be properly discovered by ‘dh_pysupport’? Put them into /usr/lib/python*/site-packages, as documented in its manpage? Thanks. That's new since the version of ‘python-support’ currently in ‘squeeze’. (The ‘dh_pysupport(1)’ manpage in version 0.8.7 still talks about detecting modules in ‘/usr/share/python-support’.) I'm attaching a source debdiff with various things that should help you reach some working package. Thank you. However, I'm still perplexed. Your changes include: = --- docutils-writer-manpage-0.1~svn.r5663/debian/docutils-writer-manpage.install +++ docutils-writer-manpage-0.1~svn.r5663/debian/docutils-writer-manpage.install @@ -1 +1 @@ -usr/share/pyshared/docutils/writers/ +usr/lib/python*/site-packages/docutils/writers/ = This appears to ignore the ‘dh_pysupport(1)’ documentation, instead relying on ‘dh_install’ to install the files explicitly. Why is this necessary? -- \ “I'm a great lover, I'll bet.” —Emo Philips | `\ | _o__) | Ben Finney pgpF6yfFj1uPv.pgp Description: PGP signature
Re: Migrating unmanaged Python library extension from ‘python-central’ to ‘python -support’
Josselin Mouette j...@debian.org writes: Le mardi 14 avril 2009 à 16:51 +1000, Ben Finney a écrit : = --- docutils-writer-manpage-0.1~svn.r5663/debian/docutils-writer-manpage.install +++ docutils-writer-manpage-0.1~svn.r5663/debian/docutils-writer-manpage.install @@ -1 +1 @@ -usr/share/pyshared/docutils/writers/ +usr/lib/python*/site-packages/docutils/writers/ = This appears to ignore the ‘dh_pysupport(1)’ documentation, instead relying on ‘dh_install’ to install the files explicitly. Why is this necessary? The former documentation in dh_pysupport was misleading. It was already not required to install files in /usr/share/python-support. Files are picked by dh_pysupport at whatever place the upstream build system installs them. What about in this case, where there *is* no upstream build system for these modules and the only supported install method is “copy the module files where you want them”? Where should I put the upstream library files so that the above ‘docutils-writer-manpage.install’ is not needed and ‘dh_pysupport’ will get them automatically? I have not come up with any combination that obviated this file. -- \“Don't worry about people stealing your ideas. If your ideas | `\ are any good, you'll have to ram them down people's throats.” | _o__)—Howard Aiken | Ben Finney pgpvz85Hq9Vk6.pgp Description: PGP signature
Re: Migrating unmanaged Python library extension from ‘python-central’ to ‘python -support’
Josselin Mouette j...@debian.org writes: Le mardi 14 avril 2009 à 22:09 +1000, Ben Finney a écrit : Where should I put the upstream library files so that the above ‘docutils-writer-manpage.install’ is not needed and ‘dh_pysupport’ will get them automatically? I have not come up with any combination that obviated this file. If there is no upstream build system, you need to replace it, and the .install file looks like the simplest way to do it. I don’t understand why you’d want to drop it. Because it's double-handling: in the ‘debian/rules’ file I specify copying the modules once, and then in ‘debian/foo.install’ I specify copying them again. I want to copy them to one location that ‘dh_pysupport’ will automatically find them, so I don't have to specify twice where they are. -- \ “Welchen Teil von ‘Gestalt’ verstehen Sie nicht? [What part of | `\‘gestalt’ don't you understand?]” —Karsten M. Self | _o__) | Ben Finney pgpRQeRyZlBZI.pgp Description: PGP signature
Re: Migrating unmanaged Python library extension from ‘python-central’ to ‘python -support’
Josselin Mouette j...@debian.org writes: Le mercredi 15 avril 2009 à 08:01 +1000, Ben Finney a écrit : Because it's double-handling: in the ‘debian/rules’ file I specify copying the modules once, and then in ‘debian/foo.install’ I specify copying them again. I want to copy them to one location that ‘dh_pysupport’ will automatically find them, so I don't have to specify twice where they are. Why are you installing them twice? dh_install is perfectly capable of installing them from the source directory. Let me try asking the question again, which I think has got lost in the shuffle: The original source has as part of its tree ‘writers/manpage.py’. The only way upstream currently supports installing this module is “copy the file to the system ‘docutils/writers/’ directory”. The only way that I know of so far to get ‘dh_pysupport’ to find and install the module correctly is: * Copy the file from ‘writers/manpage.py’ into ‘usr/lib/$(shell pyversions -d)/site-packages/docutils/writers/.’. If I omit this step, there is no indication that the modules should be in the ‘docutils/writers/’ system library directory. * Tell ‘dh_install’ to install ‘usr/lib/python*/site-packages/docutils/writers/’. If I omit this step, ‘dh_pysupport’ ignores the module and it doesn't end up in the package at all. * Tell ‘dh_pysupport’ to do its thing. I would love to collapse the first two steps somehow, but none of my experiments have led to ‘dh_pysupport’ actually finding and installing the module to the right place. -- \ “People's Front To Reunite Gondwanaland: Stop the Laurasian | `\ Separatist Movement!” —wiredog, http://kuro5hin.org/ | _o__) | Ben Finney pgpfdRReMTQTg.pgp Description: PGP signature
Re: Migrating unmanaged Python library extension from ‘python-central’ to ‘python -support’
Piotr Ożarowski pi...@debian.org writes: [Ben Finney, 2009-04-15] The only way that I know of so far to get ‘dh_pysupport’ to find and install the module correctly is: * Copy the file from ‘writers/manpage.py’ into ‘usr/lib/$(shell pyversions -d)/site-packages/docutils/writers/.’. If I omit this step, there is no indication that the modules should be in the ‘docutils/writers/’ system library directory. * Tell ‘dh_install’ to install ‘usr/lib/python*/site-packages/docutils/writers/’. If I omit this step, ‘dh_pysupport’ ignores the module and it doesn't end up in the package at all. * Tell ‘dh_pysupport’ to do its thing. dh_pysupport should be as small as possible, it should not do dh_install's job, IMO. I'm not sure why you think I'm expecting that. Just fill in .install file, and then call `dh_install; dh_pysupport` in debian/rules As I said in the original message, I'd love to just do that; but it doesn't work, as explained in the material you quoted above. -- \ “My classmates would copulate with anything that moved, but I | `\ never saw any reason to limit myself.” —Emo Philips | _o__) | Ben Finney -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Migrating unmanaged Python library extension from ‘python-central’ to ‘python -support’
Adeodato Simó d...@net.com.org.es writes: + Ben Finney (Wed, 15 Apr 2009 20:19:55 +1000): * Copy the file from ‘writers/manpage.py’ into ‘usr/lib/$(shell pyversions -d)/site-packages/docutils/writers/.’. If I omit this step, there is no indication that the modules should be in the ‘docutils/writers/’ system library directory. You’re not qualifying the destination directory. Do you mean debian/tmp/usr/lib/...? I'm not sure what you mean by “qualify”; all the directory names (including the ones you suggest?) are relative, if that's what you mean. I'm cribbing from Cyril Brulebois's suggestion, which puts the module in ‘usr/lib/$(shell pyversions -d)/site-packages/docutils/writers/’ and has that directory specified to ‘dh_install’. In that case, just use debian/pkgname/usr/lib... instead, and skip the dh_install step. That does work, thank you. This goes against the suggestions earlier that ‘dh_install’ is the right tool; I'm curious as to why you advise the opposite. -- \ “To punish me for my contempt of authority, Fate has made me an | `\ authority myself.” —Albert Einstein, 1930-09-18 | _o__) | Ben Finney -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Migrating unmanaged Python library extension from ‘python-central’ to ‘python -support’
Ben Finney ben+deb...@benfinney.id.au writes: Adeodato Simó d...@net.com.org.es writes: In that case, just use debian/pkgname/usr/lib... instead, and skip the dh_install step. That does work, thank you. I spoke too soon; ‘dh_pysupport’ fails to find the module. The install process now shows the following output: = # Manual installation, until upstream uses a build system install -d debian/docutils-writer-manpage/usr/lib/python2.5/site-packages/docutils/writers install -m 644 writers/manpage.py debian/docutils-writer-manpage/usr/lib/python2.5/site-packages/docutils/writers/ dh install dh_testroot dh_prep dh_installdirs dh_auto_install dh_install dh_installdocs dh_installchangelogs dh_installexamples dh_installman dh_installcatalogs dh_installcron dh_installdebconf dh_installcatalogs dh_installemacsen dh_installifupdown dh_installinfo dh_installinit dh_installmenu dh_installmime dh_installmodules dh_installlogcheck dh_installlogrotate dh_installpam dh_installppp dh_installudev dh_installwm dh_installxfonts dh_bugfiles dh_lintian dh_desktop dh_gconf dh_icons dh_perl dh_pysupport dh_scrollkeeper dh_usrlocal dh_link dh_compress dh_fixperms = This doesn't seem to be sufficient for ‘dh_pysupport’, which gives no output. The resulting binary package does not have the module at all. -- \ “Corporation, n. An ingenious device for obtaining individual | `\ profit without individual responsibility.” —Ambrose Bierce, | _o__) _The Devil's Dictionary_, 1906 | Ben Finney -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Migrating unmanaged Python library extension from ‘python-central’ to ‘python -support’
Adeodato Simó d...@net.com.org.es writes: dh_install would have been the tool of choice for this task, except that your destination directory is not a static string: it depends on the output of some command. Because of this, it can’t be sensibly used for this. (If pysupport looked in some directory which does not embed the version number, that’d be another story; but I don’t know about that.) Josselin earlier suggested that ‘dh_pysupport’ will still look in ‘usr/share/python-support/’ for modules. Should I expect it to work with just ‘dh_install ; dh_pysupport’ if I use the following install file: = writers/manpage.py usr/share/python-support/docutils/writers/ = Unfortunately when I try this now, the module ends up in ‘/usr/share/pyshared/writers/manpage.py’, when it needs instead to be in ‘/usr/share/pyshared/docutils/writers/manpage.py’. -- \“We have to go forth and crush every world view that doesn't | `\believe in tolerance and free speech.” —David Brin | _o__) | Ben Finney -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Migrating unmanaged Python library extension from ‘python-central’ to ‘python -support’
Piotr Ożarowski pi...@debian.org writes: [Ben Finney, 2009-04-15] Josselin earlier suggested that ‘dh_pysupport’ will still look in ‘usr/share/python-support/’ for modules. Should I expect it to work with just ‘dh_install ; dh_pysupport’ if I use the following install file: = writers/manpage.py usr/share/python-support/docutils/writers/ ^ you're missing $package here If I change this to = writers/manpage.py usr/share/python-support/docutils-writer-manpage/docutils/writers/ = it does work. After ‘dh_install’ acts on the above specification, ‘dh_pysupport’ decides that the module should go in the place I want it to go. I would never have guessed this difference in behaviour from reading the ‘dh_pysupport(1)’ manpage, and I'm not at all clear on it even now. Thanks for the continuing assistance on this. -- \ “[W]hoever is able to make you absurd is able to make you | `\unjust.” —Voltaire | _o__) | Ben Finney -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Butchered python configuration ...
itsovermyhead itsovermyh...@googlemail.com writes: Can anyone advise me how to approach this? Two aspects to this: * You should be polite to your readers and give your real name in the ‘From’ field, so it's easier for interested helpers to know you. * You should ask your question on the ‘debian-user’ mailing list; this list is for discussion of making Debian packages of Python software. Many thanks in advance. Hope that helps. -- \ “If you fell down yesterday, stand up today.” —_The Anatomy of | `\ Frustration_, H. G. Wells, 1936 | _o__) | Ben Finney -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Butchered python configuration ...
itsovermyhead itsovermyh...@googlemail.com writes: FYI - This problem was solved by a kind and clear post. See below. http://lists.debian.org/debian-user/2009/04/msg02759.html Thank you for using the correct forum for these questions; I'm glad you found the Debian resources useful. -- \ “We tend to scoff at the beliefs of the ancients. But we can't | `\scoff at them personally, to their faces, and this is what | _o__) annoys me.” —Jack Handey | Ben Finney -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: question about copyright file
Stani spe.stani...@gmail.com writes: So if I include the copyright file upstream, I need to know how to change the packaging. Should that be done in debian/rules? That's one way of doing it. You might like to join ‘debian-mentors’ (but please, drop the top-posting habit) and ask about better ways of doing it that make use of the existing packaging tools. -- \ “Faith may be defined briefly as an illogical belief in the | `\ occurrence of the improbable.” —Henry L. Mencken | _o__) | Ben Finney -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Packaging plugins for Python applications
Emilio Pozuelo Monfort po...@ubuntu.com writes: Jakub Wilk escribió: What is the correct umbrella to package a plugin for a Python application under? DPMT or PAPT? PAPT, since it's not a module Hmm? I can't see a reasonable way to package a Python application plug-in that *isn't* a module (or a Python “package”, which is essentially a library of modules). It would make more sense, in my view, to say that an application plug-in isn't an application, so it doesn't fit PAPT. -- \“Holy uncanny photographic mental processes, Batman!” —Robin | `\ | _o__) | Ben Finney pgpqgTMVQNYt5.pgp Description: PGP signature
Re: what's keeping python2.6? why is Josselin acting like a deaf man when his packages contain critical bugs?
Jan Geboers hiding@gmail.com writes: Personal attacks are not my intention, I hope my point of view isn't interpreted as such, If that is truly what you want, then you must realise that paragraphs like this: Taking into account Josselin's charming personality I'm quite sure that he wouldn't even accept an updated version of said package that I would provide to him. work directly against that. A personal attack is *exactly* what that paragraph is; please omit such sentiments from future messages if they are not your intention. -- \“None can love freedom heartily, but good men; the rest love | `\ not freedom, but license.” —John Milton | _o__) | Ben Finney -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: from python egg to debian package : a good example ?
Piotr Ożarowski pi...@debian.org writes: [Jérémy Lal, 2009-08-18] i'm willing to package a python module (orbited, see http://orbited.org). I suppose there's a clever way when the said module is a python egg. There's tar.gz on PyPi, no need to use Egg. This is true for the ‘orbited’ distribution, but only because the distribution owner has uploaded a tarball. PyPI doesn't generate any of those files, and none of them will necessarily be there; it hosts the files uploaded by the distribution owner. -- \ “Two possibilities exist: Either we are alone in the Universe | `\ or we are not. Both are equally terrifying.” —Arthur C. Clarke, | _o__) 1999 | Ben Finney pgppH7qau0NkG.pgp Description: PGP signature
Re: from python egg to debian package : a good example ?
Piotr Ożarowski pi...@debian.org writes: Can you point me to a project that is providing eggs only? For a while my own did, until I realised that tarballs were a better option. I've also seen distribution entries that have no files at all, just meta-data. My point is that it needs to be realised that *if* a distribution isn't providing tarballs, that's not because PyPI has failed; it makes no guarantee that *any* distribution files are downloadable. Therefore one should not rely on them being available. -- \ “The lift is being fixed for the day. During that time we | `\regret that you will be unbearable.” —hotel, Bucharest | _o__) | Ben Finney -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: from python egg to debian package : a good example ?
Jérémy Lal je...@edagames.com writes: Indeed the tarball contains setup.py, and dh_pycentral did the job. Note again, though, that new packaging work shouldn't rely on ‘python-central’; it has many problems that are tedious to recover from. Instead, use ‘python-support’. -- \ “About four years ago, I was — no, it was yesterday.” —Steven | `\Wright | _o__) | Ben Finney -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: will 2.6 be default?
Josselin Mouette j...@debian.org writes: Le mercredi 26 août 2009 à 10:14 +0200, Tshepang Lekhonkhobe a écrit : I saw recently that RT did not list 2.6 as default Python as a release goal. I also saw a thread talking about the problems related to 2.6. Does this mean Squeeze won't use it by default or are u guys working on it? In the current state of affairs and given the plans of the Python maintainers By this, do you mean “the plans of the maintainers of the Debian maintainers of Python”, or “the plans of the upstream maintainers of Python”? there will be likely no python2.6 (even as non-default) in squeeze. Can this situation be improved by input from enthustic volunteers, even those without specific skills in the Debian package of Python? I'm confident that, if the right coordination of effort and publicity of the necessary to-do tasks were applied, there would be ample willingness From Debian members who want Python 2.6 in Debian Squeeze. -- \ “A new swimming pool is rapidly taking shape since the | `\contractors have thrown in the bulk of their workers.” | _o__) newspaper article, east Africa | Ben Finney pgpK2CJHlWTld.pgp Description: PGP signature
