Re: [Distutils] issues with namespace packages on Debian Squeeze and Python 2.6
On 22-03-11 18:57, Carl Meyer wrote: Only: buildout cannot detect the eggs in their non-standard locations as buildout obviously doesn't have the ubuntu setuptools' fix... This sounds more likely to be caused by not having the site.py changes I mentioned above. IIRC buildout 1.5 uses python -S to avoid the automatic import of site.py, so it would never see the Debian/Ubuntu modifications in site.py. As long as buildout uses -S, I think the only fix for that would be for buildout's detect system-wide eggs feature to add in explicit workaround/support for dist-packages. This is what virtualenv does. Just making sure: you're suggesting a debian-specific workaround in buildout? Buildout maintainers: would adding such a workaround be OK with you? Reinout ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] issues with namespace packages on Debian Squeeze and Python 2.6
Maybe not a debian-specific workaround, but a setting like: [buildout] additional-site-packages = /usr/lib/python2.6/dist-packages /usr/local/lib/python2.6/dist-packages On Wed, Mar 23, 2011 at 14:42, Reinout van Rees rein...@vanrees.org wrote: On 22-03-11 18:57, Carl Meyer wrote: Only: buildout cannot detect the eggs in their non-standard locations as buildout obviously doesn't have the ubuntu setuptools' fix... This sounds more likely to be caused by not having the site.py changes I mentioned above. IIRC buildout 1.5 uses python -S to avoid the automatic import of site.py, so it would never see the Debian/Ubuntu modifications in site.py. As long as buildout uses -S, I think the only fix for that would be for buildout's detect system-wide eggs feature to add in explicit workaround/support for dist-packages. This is what virtualenv does. Just making sure: you're suggesting a debian-specific workaround in buildout? Buildout maintainers: would adding such a workaround be OK with you? Reinout ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
[Distutils] [issue123] [PATCH] Tolerate responses with multiple Content-Length headers
New submission from Tres Seaver tsea...@palladion.com:
Some servers (e.g., wwwsearch.sourceforge.net) apparently send multiple
'Content-Length' headers, which causes setuptools to barf trying to convert
a 'length, length' string to an integer.
This bug breaks installing 'mechanize', which lists wwwsearch.sourceforge.net
as its Download-URL, and therefore causes a bunch of Zope-related tests to fail
(e.g., https://mail.zope.org/pipermail/cmf-tests/2011-March/014576.html ).
The attached patch uses 'headers.getheaders('Content-Length')[0] to use only
the first value found.
--
assignedto: pje
files: setuptools-multi_content_length.patch
messages: 598
nosy: pje, tseaver
priority: urgent
status: unread
title: [PATCH] Tolerate responses with multiple Content-Length headers
Added file:
http://bugs.python.org/setuptools/file75/setuptools-multi_content_length.patch
___
Setuptools tracker setupto...@bugs.python.org
http://bugs.python.org/setuptools/issue123
___=== modified file 'setuptools/package_index.py'
--- setuptools/package_index.py 2010-02-01 16:42:04 +
+++ setuptools/package_index.py 2011-03-23 14:06:46 +
@@ -550,7 +550,9 @@
bs = self.dl_blocksize
size = -1
if content-length in headers:
-size = int(headers[Content-Length])
+# Some servers return multiple Content-Length headrers :(
+content_length = headers.getheaders(Content-Length)[0]
+size = int(content_length)
self.reporthook(url, filename, blocknum, bs, size)
tfp = open(filename,'wb')
while True:
___
Distutils-SIG maillist - Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] issues with namespace packages on Debian Squeeze and Python 2.6
On Wed, Mar 23, 2011 at 9:42 AM, Reinout van Rees rein...@vanrees.org wrote: On 22-03-11 18:57, Carl Meyer wrote: Only: buildout cannot detect the eggs in their non-standard locations as buildout obviously doesn't have the ubuntu setuptools' fix... This sounds more likely to be caused by not having the site.py changes I mentioned above. IIRC buildout 1.5 uses python -S to avoid the automatic import of site.py, so it would never see the Debian/Ubuntu modifications in site.py. As long as buildout uses -S, I think the only fix for that would be for buildout's detect system-wide eggs feature to add in explicit workaround/support for dist-packages. This is what virtualenv does. Just making sure: you're suggesting a debian-specific workaround in buildout? Buildout maintainers: would adding such a workaround be OK with you? I abhor screwing w site.py, but buildout is already doing so. I believe it copies site.py so it *should* work with debian modifications. I don't really understand this code and honestly don't want to. It was contributed by someone at and for Ubuntu so I'd expect it to work with debian. I would submit a bug report and hopefully, they'll look at it. In the long term, I'd really like to move this (site.py copying) code out of buildout into recipes, as I don't want to maintain it. In the longer term, I'd love this to get addresses by the pythonv work somehow. :) Jim -- Jim Fulton http://www.linkedin.com/in/jimfulton ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] New buildout options: checksums and allow-omitted-checksums
On Tue, Mar 22, 2011 at 12:51:35PM +1300, Greg Ewing wrote: Thomas Lotze wrote: After some further offline discussion, I'd like to suggest using MD5 as the default algorithm, though. Warnings against using md5 are mainly about cryptographic security, aren't they? For just detecting accidental corruption it should still be good enough. Yes, that's my understanding too. (My only point for raising this was to consider a future-proof syntax for specifying the checksums, so that we're not locked in the past when the world moves on.) Marius Gedminas -- At most companies, programmers aren't trusted with words that a user might actually see (and for good reason, much of the time). -- Joel Spolski signature.asc Description: Digital signature ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
[Distutils] the usecase of continious integration based release-management (which could use more support on the ds2 side)
Hi, i'd like to propose making the work-flow of creating releases by just pushing vcs tags to a ci system as easy as possible personally all i ever want to do to release a new version is:: $vcs tag $version $vcs push currently that would require various nasty hacks to get the version meta-data static on sdist and to grab the version number in a setup hook there are various ways to ease this, the ones i imagined are a) provide a hook to get the version, make the version static on sdist/upload pro: straightforward, simple cons: kind of a hack b) provide support for multiple setup-hooks and support for command mixin's pro: generic way to do it cons: needs more code, more stuff in setup.cfg signature.asc Description: This is a digitally signed message part ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] pythonv: let's also make sure the standard Python install includes an isolated python
Fred Drake wrote: On Fri, Mar 18, 2011 at 9:50 PM, Greg Ewing greg.ew...@canterbury.ac.nz wrote: We don't have to make it look so Windows-like, though. We could use something more cheerful such as 'python.nothisisnotthedirectory'. Yes, but... the sad part is that a turd has to be added, or the name changed in even less satisfactory ways. Case-senselessness is still senseless. /me mourns the loss of case-sense in pop operating systems. Actually, loss is not quite what happened here. Unix-derived systems (Unix, Linux, *BSD) are somewhat unusual in having case-sensitive file systems. Of the alphabet soup of operating systems that I've used, I can remember case sensitive files systems in the Unix-like systems, Plan 9, and Apple II DOS -- but the Apple II doesn't have lower case letters on the keyboard/display, so I'm not sure it counts. I used to think that case-sensitive identifiers are a good idea, but I now think that it is just too error-prone to use identifiers that differ only in case. Also, it's not portable... :) b.t.w. The extension is .cfg because RT-11 stored file names in a character set called Radix 50 that could pack 3 characters into a 16 bit word. CP/M pretty obviously copied RT-11, MS-DOS copied CP/M, and MS Windows was originally a GUI framework for MS-DOS. Meanwhile, Unix initially ran on other DEC systems, so a lot of early Unix users had contact with RT-11 or its descendants, and re-used some of the same conventions. So, We use .cfg because we have calling it that since 1970... Interesting, but perhaps not a particularly compelling reason. :) sniff - what's that smell? Oh yeah -- old farts... ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] the usecase of continious integration based release-management (which could use more support on the ds2 side)
Mark Sienkiewicz wrote: Maybe you should go the other way: Put the version number in your source code. Make a short script that picks out the version number and constructs a tag name for the vcs. In my projects I tend to keep the definitive version number in the Makefile, and have a make target that generates a version.py file from it. This is convenient because the Makefile often needs the version number for other things like creating release tarballs. Tagging vcs commits would be another use. -- Greg ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] the usecase of continious integration based release-management (which could use more support on the ds2 side)
Le 23/03/2011 19:20, Ronny Pfannschmidt a écrit : Hi, Hey ronny ! i'd like to propose making the work-flow of creating releases by just pushing vcs tags to a ci system as easy as possible That's an usage a lot of people have, +1 to make it easy to do in a few steps. personally all i ever want to do to release a new version is:: $vcs tag $version $vcs push Do you mean pysetup upload (or whatever similar), or are you thinking about a vcs hook that generates the setup.cfg and upload for you ? What tools are we talking about ? distutils? distutils2? setuptools/distribute? The way to do it with distutils2 would be to register a hook able to get information from the vcs and put it in the setup.cfg. a) provide a hook to get the version, make the version static on sdist/upload pro: straightforward, simple cons: kind of a hack why are you considering it a hack ? seems the right way to me. b) provide support for multiple setup-hooks and support for command mixin's pro: generic way to do it cons: needs more code, more stuff in setup.cfg multiple setup-hooks ? Doesnt seems clear to me, can you clarify ? -- Alexis — http://notmyidea.org ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] the usecase of continious integration based release-management (which could use more support on the ds2 side)
On Wed, 2011-03-23 at 16:59 -0400, Mark Sienkiewicz wrote: Ronny Pfannschmidt wrote: Hi, i'd like to propose making the work-flow of creating releases by just pushing vcs tags to a ci system as easy as possible personally all i ever want to do to release a new version is:: $vcs tag $version $vcs push currently that would require various nasty hacks to get the version meta-data static on sdist and to grab the version number in a setup hook Maybe you should go the other way: Put the version number in your source code. Make a short script that picks out the version number and constructs a tag name for the vcs. Raise an error if the tag already exists. i never ever want to have a version number of the project outside of a vcs tag inside the vcs repo also its convient to automatically imply different version numbers for each commit (which includes a dev marker + a revision id) This method is easy to implement for your project alone, it is easy to distribute to others who want to do the same thing, and there are no nasty hacks involved. For example, % python tagdist.py You didn't change the version number! % emacs setup.cfg % python tagdist.py Tagging release 0.0.2 % If you find it works well in practice, you might then propose to move the script into python setup.py tagdist. signature.asc Description: This is a digitally signed message part ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] the usecase of continious integration based release-management (which could use more support on the ds2 side)
Greg Ewing greg.ew...@canterbury.ac.nz writes: In my projects I tend to keep the definitive version number in the Makefile, and have a make target that generates a version.py file from it. This is convenient because the Makefile often needs the version number for other things like creating release tarballs. Tagging vcs commits would be another use. I often do something similar, but IMO simpler: the definitive version string (note: version strings are rarely single numbers!) is kept as the sole content of a file at the top of the project tree, named ‘version’. That way, it's available equally to anything that can read text content from a file – the Makefile, any program code, even many configuration files. -- \ “I went to a general store. They wouldn't let me buy anything | `\ specifically.” —Steven Wright | _o__) | Ben Finney ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] the usecase of continious integration based release-management (which could use more support on the ds2 side)
On Wed, 2011-03-23 at 22:47 +, Alexis Métaireau wrote: Le 23/03/2011 19:20, Ronny Pfannschmidt a écrit : Hi, Hey ronny ! i'd like to propose making the work-flow of creating releases by just pushing vcs tags to a ci system as easy as possible That's an usage a lot of people have, +1 to make it easy to do in a few steps. personally all i ever want to do to release a new version is:: $vcs tag $version $vcs push Do you mean pysetup upload (or whatever similar), or are you thinking about a vcs hook that generates the setup.cfg and upload for you ? pysetup upload would happen somewhere else, most likely a continious build/integration server What tools are we talking about ? distutils? distutils2? setuptools/distribute? mostly distutils2, the rest is in deprecation/better not change limbo anyway The way to do it with distutils2 would be to register a hook able to get information from the vcs and put it in the setup.cfg. i tried hacking that up, it also needs a hook in the sdist command to statically put the data there a) provide a hook to get the version, make the version static on sdist/upload pro: straightforward, simple cons: kind of a hack why are you considering it a hack ? seems the right way to me. its the implementation of a single dynamic metadata item as kind of special case b) provide support for multiple setup-hooks and support for command mixin's pro: generic way to do it cons: needs more code, more stuff in setup.cfg multiple setup-hooks ? Doesnt seems clear to me, can you clarify ? people might want to do more than just the hook for the version it shouldn't be necessary to manually write functions that combine those hooks, if all that's necessary is call in order signature.asc Description: This is a digitally signed message part ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] the usecase of continious integration based release-management (which could use more support on the ds2 side)
On 23-03-11 20:20, Ronny Pfannschmidt wrote: personally all i ever want to do to release a new version is:: $vcs tag $version $vcs push currently that would require various nasty hacks to get the version meta-data static on sdist and to grab the version number in a setup hook This means a bit of machinery on the server side, basically. I'm doing this on my laptop with zest.releaser (see pypi). I just enter fullrelease and press enter a few times and it is ready. It grabs the version number from setup.py. It proposes that version number as the new tag. It then increases the version number and commits that one (with a dev marker). It does a bit more, like updating your changelog with a new header after releasing and by recording your release date in that very same changelog. = I think this is best handled on the client's side: the tag you're making is tied to quite a lot of things and I think setup.py's version is the best source of that. Reinout ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
