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
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
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
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
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
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
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
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
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
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
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
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
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
13 matches
Mail list logo
