Hi Jim,
On 03/01/2013 12:35, Jim Fulton wrote:
Yeah, the stuff that buildout.dumppickedversions and buildout_versions
provide should just be in the core.
Jim, if I worked up a pull request would you merge it?
Maybe :) I tried to look at buildout.dumppickedversions and
buildout_versions and
On 03/01/2013 16:09, Reinout van Rees wrote:
On 03-01-13 14:03, Marius Gedminas wrote:
buildout-versions is a clone of buildout.dumppickedversions
Note that one of the big improvements of buildout-versions over
buildout.dumppickedversions is that it deals more graceful with
differently-cased
From: PJ Eby p...@telecommunity.com
FWIW, the original reason I argued for relative paths in PEP 376 is
supporting installations that are shared across architectures for
cross-platform development. At OSAF, it was common to have a single
installation directory shared by a Linux, Mac,
Please consider a user scenario quite common: the use of DESTDIR while
planning ahead for path resolution.
Linux distro use DESTDIR (and I believe autoconf-related things) uses
this env variable to set an alternative root, so:
prefix=/usr
sysconfdir=/etc
DESTDIR=/foo/bar
- bindir (if
On Fri, 2013-01-04 at 09:17 +, Vinay Sajip wrote:
From: PJ Eby p...@telecommunity.com
FWIW, the original reason I argued for relative paths in PEP 376 is
supporting installations that are shared across architectures for
cross-platform development. At OSAF, it was common to
On 4 January 2013 09:37, Chris McDonough chr...@plope.com wrote:
I've never really understood the idea that mere installation of a
distribution should need to write to completely arbitrary locations on
the filesystem. Personally, if the software in my distribution needs
things to be put in
Absolute path do make some sense in different contexts.
For example a server (system wide installed) as administrator I'm
expecting my config files to be under /etc.
As user (personal) I'm expecting my config files (for the same
application) could be under ~/.somewhere
A in-between could
On 4 January 2013 11:06, Antonio Cavallo a.cava...@cavallinux.eu wrote:
And I'm talking about **applications** (eg. some code + some library
depending on an installed python stack) vs **libraries** (code simply
installed along the current python stack).
That's the point, though. In general,
On Fri, Jan 4, 2013 at 2:42 AM, Chris Withers ch...@simplistix.co.uk wrote:
...
thing and http://packages.python.org/buildout_versions/index.html doesn't
state
what problem it solves.
Try http://packages.python.org/buildout_versions/use.html
Right, that lacks the summary you previde below.
On 04/01/2013 13:03, Jim Fulton wrote:
On Fri, Jan 4, 2013 at 2:42 AM, Chris Withersch...@simplistix.co.uk wrote:
...
thing and http://packages.python.org/buildout_versions/index.html doesn't
state
what problem it solves.
Try http://packages.python.org/buildout_versions/use.html
Right,
On Fri, Jan 04, 2013 at 01:15:05PM +, Chris Withers wrote:
On 04/01/2013 13:03, Jim Fulton wrote:
On Fri, Jan 4, 2013 at 2:42 AM, Chris Withersch...@simplistix.co.uk wrote:
- if a python version is specified, blow up if a different version is used
to run buildout.
That's an interesting
On 04/01/2013 14:32, Jim Fulton wrote:
On Fri, Jan 4, 2013 at 8:15 AM, Chris Withersch...@simplistix.co.uk wrote:
...
- if a file is specified (which can be buildout.cfg), append those those
un-pinned versions to the end of that file
Got it.
...rather than just doing the right thing and
On Fri, Jan 4, 2013 at 8:15 AM, Chris Withers ch...@simplistix.co.uk wrote:
...
- if a file is specified (which can be buildout.cfg), append those those
un-pinned versions to the end of that file
Got it.
...rather than just doing the right thing and telling you what it did ;-)
I have no
Jim Fulton j...@zope.com writes:
Please try it and let me know if you have any problems. If I don't
hear anything, I'll release 1.7.0 final in a week or so.
I tried upgrading one of my projects to 1.7.0b2 (from 1.6.0), and
something has changed wrt the location where the buildout script is
I've never really understood the idea that mere installation of a
distribution should need to write to completely arbitrary locations on
the filesystem. Personally, if the software in my distribution needs
things to be put in places that aren't circumscribed by the install
machinery
From: Paul Moore p.f.mo...@gmail.com
I agree - on Windows, I would generally consider a package that
installed anything outside of the Python installation to be pretty
much broken (it wouldn't work properly in a virtualenv, for example).
Not necessarily - for example, I did some work on
Jim Fulton j...@zope.com writes:
Please try it and let me know if you have any problems. If I don't
hear anything, I'll release 1.7.0 final in a week or so.
I notice a little typo in the CHANGES.txt, where there is a duplicated
entry for 1.7.0b1, instead of a new 1.7.0b2.
ciao, lele.
--
On Fri, 2013-01-04 at 11:43 +, Paul Moore wrote:
On 4 January 2013 11:06, Antonio Cavallo a.cava...@cavallinux.eu wrote:
And I'm talking about **applications** (eg. some code + some library
depending on an installed python stack) vs **libraries** (code simply
installed along the current
On Fri, Jan 4, 2013 at 2:54 PM, Alex Clark acl...@aclark.net wrote:
...
Personally, when I run -v or -vv or - I expect to see debug output, not
necessarily something that is formatted for other purposes… for whatever
that is worth.
-v is verbose.
-vv is debug
I don't think additional vs
On Fri, Jan 4, 2013 at 4:17 AM, Vinay Sajip vinay_sa...@yahoo.co.uk wrote:
The other thing is that using *only* relative paths doesn't cut it - there
are circumstances where you write files outside site-packages, so you would
need absolute paths for those files (or incredibly convoluted
On 1/4/2013 7:11 PM, PJ Eby wrote:
On Fri, Jan 4, 2013 at 4:17 AM, Vinay Sajip vinay_sa...@yahoo.co.uk wrote:
The other thing is that using *only* relative paths doesn't cut it - there
are circumstances where you write files outside site-packages, so you would
need absolute paths for those
21 matches
Mail list logo
