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: 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: 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: 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]
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: 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]
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: 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]
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]
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: 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]
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]
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]
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]
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: 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: 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]
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: 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]
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 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
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: 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: 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
(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
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]
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: 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]
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: 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]
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: 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]
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: 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]
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]
