On Fri, Oct 09, 2009 at 05:13:16PM +0100, Chris Withers wrote:
> Toshio Kuratomi wrote:
>> On Fri, Oct 09, 2009 at 04:04:06PM +0100, Chris Withers wrote:
>>> Toshio Kuratomi wrote:
On Fri, Oct 09, 2009 at 03:28:57PM +0100, Chris Withers wrote:
> In this case, which I suspect is extremely r
2009-10-09 00:27:41 Tarek Ziadé napisał(a):
> On Fri, Oct 9, 2009 at 12:03 AM, Toshio Kuratomi wrote:
> > On Thu, Oct 08, 2009 at 11:07:13PM +0200, Arfrever Frehtes Taifersar
> > Arahesis wrote:
> >> 2009-10-04 23:52:25 Sridhar Ratnakumar napisał(a):
> >> > On Sun, 04 Oct 2009 13:41:06 -0700, Tar
On Fri, Oct 9, 2009 at 12:08 PM, Chris Withers wrote:
> distutils.entrypoints would seem to be the sensible place.
Why's that? On the whole, I don't think entry points are specific to
building & bundling, which is what distutils is all about.
Entry points are about packages being able to provid
On Fri, Oct 09, 2009 at 06:05:50PM +0200, Tarek Ziadé wrote:
> On Fri, Oct 9, 2009 at 5:42 PM, Chris Withers wrote:
> > Tarek Ziadé wrote:
> >>
> >> - The code is splitted in many packages and might be distributed under
> >> several distributions.
> >>
> >> - distribute.resources: that's the old
Probably all these discussions are better on distutils-sig (just
copying python-dev to note the movement of the discussion)
On Fri, Oct 9, 2009 at 11:49 AM, Michael Foord
wrote:
>> Outside of binaries on Windows, I'm still unsure if installing eggs
>> serves a useful purpose. I'm not sure if egg
I'm crossposting to continue on distutils.
Ian Bicking a écrit :
> On Fri, Oct 9, 2009 at 3:54 AM, kiorky wrote:
> Well, if multi-versioned installs were deprecated, it would not be
> necessary to use Setuptools' style of script generation. Instead you
> could simply dereference the entry point,
[moved to disutils-sig]
Ian Bicking wrote:
Well, if multi-versioned installs were deprecated, it would not be
necessary to use Setuptools' style of script generation. Instead you
could simply dereference the entry point, calling the underlying
function directly in the script. This detail is pr
On Fri, Oct 09, 2009 at 01:24:50PM -, exar...@twistedmatrix.com wrote:
> On 12:25 pm, be...@zope.com wrote:
> >On Thu, Oct 8, 2009 at 6:40 PM, Zooko Wilcox-O'Hearn
> > wrote:
> >>
> >>What we do in the Tahoe-LAFS project is we don't count down to a
> >>future
> >>version, we only count up from
Stanley A. Klein wrote:
> Windows and Mac are fundamentally single user systems that have added
> capabilities for multiple users and are intended to be used with
> proprietary software. Those considerations lead to minimal dependencies
> among packages (each proprietary provider needs to contro
On Fri, Oct 9, 2009 at 6:19 PM, Chris Withers wrote:
>> A specific bootstrap.py script for distribute is possible, and I
>> happen to have it finished now :
>>
>> $ wget http://ziade.org/bootstrap.py
>
> I'll certainly try this out, but I'm not using buildout trunk anywhere. Does
> it work with th
Jim Fulton wrote:
On Fri, Oct 9, 2009 at 11:08 AM, Chris Withers wrote:
Hi All,
bootstrap.py contains the following hard coded url:
exec urllib2.urlopen('http://peak.telecommunity.com/dist/ez_setup.py'
).read() in ez
With hindsight, this seems like a bad idea.
I don't s
Tarek Ziadé wrote:
My suggestion would be for bootstrap.py to include the code in ez_setup.py,
but that seems a little heavyweight. I guess this will all be solved when
the standard library includes modules to download packages from PyPI and
install them. But what to do in the meantime?
zc.buil
Toshio Kuratomi wrote:
On Fri, Oct 09, 2009 at 04:04:06PM +0100, Chris Withers wrote:
Toshio Kuratomi wrote:
On Fri, Oct 09, 2009 at 03:28:57PM +0100, Chris Withers wrote:
In this case, which I suspect is extremely rare anyway, you'll need
to have setuptools installed already.
So, in *any*
Ian Bicking wrote:
I think one (pjenvey) was an experiment, and another is actually a
released virtualenv-distribute package (updating the name in setup.py,
etc). And the third, I dunno.
Anyway -- I'm reluctant to switch virtualenv to distribute right now,
as I'm not confident it is ready for p
On Fri, Oct 09, 2009 at 04:04:06PM +0100, Chris Withers wrote:
> Toshio Kuratomi wrote:
>> On Fri, Oct 09, 2009 at 03:28:57PM +0100, Chris Withers wrote:
>>> In this case, which I suspect is extremely rare anyway, you'll need
>>> to have setuptools installed already.
>>>
>>> So, in *any* of these
Ian Bicking a écrit :
> On Fri, Oct 9, 2009 at 5:54 AM, Chris Withers wrote:
>> kiorky wrote:
> I think one (pjenvey) was an experiment, and another is actually a
> released virtualenv-distribute package (updating the name in setup.py,
> etc). And the third, I dunno.
The third (mine) was a bu
On Fri, Oct 9, 2009 at 5:54 AM, Chris Withers wrote:
> kiorky wrote:
>>
>> Hi Lennart,
>>
>> If i read 'virtualenv-distribute 1.3.4.2 on pypi'
>> I can do some googling or even do some Pypi searching for
>> 'virtualenv-distribute'.
>>
>> Thus, the first link found may be [1].
>>
>> On this link,
On Fri, Oct 9, 2009 at 11:08 AM, Chris Withers wrote:
> Hi All,
>
> bootstrap.py contains the following hard coded url:
>
> exec urllib2.urlopen('http://peak.telecommunity.com/dist/ez_setup.py'
> ).read() in ez
>
> With hindsight, this seems like a bad idea.
I don't see a good
On Fri, Oct 9, 2009 at 5:08 PM, Chris Withers wrote:
> Hi All,
>
> bootstrap.py contains the following hard coded url:
>
> exec urllib2.urlopen('http://peak.telecommunity.com/dist/ez_setup.py'
> ).read() in ez
>
> With hindsight, this seems like a bad idea. For example, with th
On Fri, 09 Oct 2009 04:03:52 -0700, Chris Withers
wrote:
Sridhar Ratnakumar wrote:
This release includes a new packaging tool by activestate called Python
Package Manager (PyPM).
Is PyPM available separately?
No, PyPM comes only with ActivePython (just like PPM does with ActivePerl).
H
Hi All,
bootstrap.py contains the following hard coded url:
exec urllib2.urlopen('http://peak.telecommunity.com/dist/ez_setup.py'
).read() in ez
With hindsight, this seems like a bad idea. For example, with the
ridiculous situation we currently have with setuptools and dis
On Friday,2009-10-09, at 6:25 , Benji York wrote:
On Thu, Oct 8, 2009 at 6:40 PM, Zooko Wilcox-O'Hearn
wrote:
What we do in the Tahoe-LAFS project is we don't count down to a
future
version, we only count up from a past version. This is also what
Twisted
does (no coincidence -- we pro
Toshio Kuratomi wrote:
On Fri, Oct 09, 2009 at 03:28:57PM +0100, Chris Withers wrote:
In this case, which I suspect is extremely rare anyway, you'll need to
have setuptools installed already.
So, in *any* of these cases, specifying setuptools as a requirement
seems like a total waste of tim
Tarek Ziadé a écrit :
> On Fri, Oct 9, 2009 at 3:32 PM, kiorky wrote:
>> And also, to use them together, what a hell. For package A i need 0.6 (hard
>> requirement), for package B i need 0.7 (hard requirement), for C i need 0.6.
>> C
>> depend on A which depends on B. I also have no sort of co
Andrew Straw wrote:
Chris Withers wrote:
I'm +1 on the branch having a version of 1.6.3~dev after 1.6.3 has
been released, and I like 2.0.0pre1 too :-)
I'm -1 on "~" meaning afterwards, because in Debian package versions it
means the exact opposite.
I'm neutral on the exact spelling, I just l
On Fri, Oct 09, 2009 at 03:28:57PM +0100, Chris Withers wrote:
>
> In this case, which I suspect is extremely rare anyway, you'll need to
> have setuptools installed already.
>
> So, in *any* of these cases, specifying setuptools as a requirement
> seems like a total waste of time...
>
> Now, w
Chris Withers wrote:
> I'm +1 on the branch having a version of 1.6.3~dev after 1.6.3 has
> been released, and I like 2.0.0pre1 too :-)
I'm -1 on "~" meaning afterwards, because in Debian package versions it
means the exact opposite.
-Andrew
___
Distutil
On Fri, Oct 09, 2009 at 09:21:29AM -0400, Carl Meyer wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Chris Withers wrote:
> The downside here is that it introduces one more wrinkle for installers
> to worry about handling correctly. There are strong use cases for the
> single bit "req
Chris Withers a écrit :
> Tarek Ziadé wrote:
>> I think the word "fork" here, in DVCS principles, just means that you
>> copy a repository
>> to work with, and eventually ask for the main repo to merge the changes.
>
> So what's the main repo?
>
> What one of these three options should someone
On Fri, Oct 9, 2009 at 4:34 PM, Chris Withers wrote:
> Tarek Ziadé wrote:
>>
>> Sorry I won't run a new poll again, Distribute is the name.
>>
>> Besides, it's already on page #1 on google when I type 'python
>> disribute' or 'distribute python'
>
> *shrugs*
>
> I will state now that I will fight
exar...@twistedmatrix.com wrote:
I'm not sure how zooko does this for Tahoe, but with Twisted (with which
we don't do "betas" but we do do "pre-releases") if we were to start
getting ready for 2.0.0, then we would create a release branch and
change the version in that release branch to 2.0.0pre
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Chris Withers wrote:
> Carl Meyer wrote:
>> The downside here is that it introduces one more wrinkle for installers
>> to worry about handling correctly.
>
> How so?
Write some more metadata, figure out whether to write it to
already-installed pac
Tarek Ziadé wrote:
Sorry I won't run a new poll again, Distribute is the name.
Besides, it's already on page #1 on google when I type 'python
disribute' or 'distribute python'
*shrugs*
I will state now that I will fight tooth and nail before anything called
"distribute" gets into the stdlib
Carl Meyer wrote:
The downside here is that it introduces one more wrinkle for installers
to worry about handling correctly.
How so?
Chris
--
Simplistix - Content Management, Batch Processing & Python Consulting
- http://www.simplistix.co.uk
___
Hanno Schlichting wrote:
I assume most packages Reinout uses (like all zope.* packages) use
namespace packages. So they actually do depend during runtime on the
pkg_resources module, which happens to be available from either the
distribute or setuptools distribution. So one of them should be
spe
kiorky wrote:
Lennart Regebro a écrit :
2009/10/9 Tarek Ziadé :
The *whole* point of Distribute 0.6.x is to be backward compatible, meaning
that if virtualenv switch to it, you will not even notice it.
I guess the point is that is should still work even if you don't want
to switch to distribut
Tarek Ziadé wrote:
I think the word "fork" here, in DVCS principles, just means that you
copy a repository
to work with, and eventually ask for the main repo to merge the changes.
So what's the main repo?
What one of these three options should someone looking to use
virtualenv-distribute tak
Hanno Schlichting wrote:
work on the UCS2/UCS4 build problem in PyPM. As a result the following
has been noted (http://workspace.activestate.com/sridharr/pypm/ticket/83):
"Jan further commented that we should not be bothering to make PyPM
work with custom builds of Python other than ActivePython
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
exar...@twistedmatrix.com wrote:
> By doing this, I think you're dooming any Python package uninstaller to
> be unpleasantly slow.
The process of searching for orphaned packages may be relatively slow on
a system with many installed packages. I'm no
On 01:45 pm, c...@dirtcircle.com wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Alex wrote:
REQUESTED is fine, but I don't understand how the arguments apply,
given
> that I'm not proposing to record information like _which_ package it
was
> a dependency of. The same single bit (litera
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Alex wrote:
> REQUESTED is fine, but I don't understand how the arguments apply, given
> > that I'm not proposing to record information like _which_ package it was
> > a dependency of. The same single bit (literally) of information is
> > tracked eith
On Fri, Oct 9, 2009 at 3:32 PM, kiorky wrote:
>> Why they can't ?
>
> As i understood all those readings, packages for 0.6 and 0.7 will be
> installable
> with the appropriate distribute version, thus side by side, but for me, they
> may
> be incompatibles together.
They "may" be ? what do you
kiorky kirjoitti:
Tarek Ziadé a écrit :
On Fri, Oct 9, 2009 at 2:43 PM, kiorky wrote:
Hi tarek,
Tarek Ziadé a écrit :
The *whole* point of Distribute 0.6.x is to be backward compatible, meaning
that if virtualenv switch to it, you will not even notice it.
Living in
Tarek Ziadé a écrit :
> On Fri, Oct 9, 2009 at 2:43 PM, kiorky wrote:
>> Hi tarek,
>>
>> Tarek Ziadé a écrit :
>>
>>> The *whole* point of Distribute 0.6.x is to be backward compatible, meaning
>>> that if virtualenv switch to it, you will not even notice it.
>> Living in my 0.6.x snail sandbox
On 12:25 pm, be...@zope.com wrote:
On Thu, Oct 8, 2009 at 6:40 PM, Zooko Wilcox-O'Hearn
wrote:
What we do in the Tahoe-LAFS project is we don't count down to a
future
version, we only count up from a past version. This is also what
Twisted
does (no coincidence -- we probably got the idea f
Carl Meyer kirjoitti:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Toshio Kuratomi wrote:
I would say REQUESTED due to my arguments for not recording
installed-as-package-dependency.
REQUESTED is fine, but I don't understand how the arguments apply, given
that I'm not proposing to re
On Fri, Oct 9, 2009 at 3:14 PM, Jim Fulton wrote:
> On Fri, Oct 9, 2009 at 7:57 AM, Hanno Schlichting wrote:
>> On Fri, Oct 9, 2009 at 1:07 PM, Chris Withers wrote:
>> I assume most packages Reinout uses (like all zope.* packages) use
>> namespace packages. So they actually do depend during runt
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Chris Withers wrote:
> Ian Bicking wrote:
>> I can imagine adding a little information, basically a log of when and
>> why and who installed the package. For instance:
>>
>> agent: pip 0.5
>> install-date: 2009-10-08T13:44:00UTC
>> installed-for
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Toshio Kuratomi wrote:
> I would say REQUESTED due to my arguments for not recording
> installed-as-package-dependency.
REQUESTED is fine, but I don't understand how the arguments apply, given
that I'm not proposing to record information like _which_
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Gediminas Paulauskas wrote:
> For backwards compatibility already installed packages have to be
> treated as manually installed, because it is not known why they were
> installed. So the presence of a new file or flag has to signify that
> it was AUTO_
On Fri, Oct 9, 2009 at 7:57 AM, Hanno Schlichting wrote:
> On Fri, Oct 9, 2009 at 1:07 PM, Chris Withers wrote:
>> Reinout van Rees wrote:
>>>
>>> - Do my libraries have to list a dependency on distribute or on
>>> setuptools?
>>> Everything zopish has a 'setuptools >= 0.6c9' in it.
>>
>> They s
Ian Bicking writes:
> So after creating, say, version 0.3.1, I always mark a package as
> 0.3.2dev.
Why not just mark it 0.3.2 during development, and change the version
string in a later revision if warranted?
> But this is annoying, you might never create a version 0.3.2 (e.g.,
> 0.4 might be
On Fri, Oct 9, 2009 at 2:43 PM, kiorky wrote:
> Hi tarek,
>
> Tarek Ziadé a écrit :
>
>> The *whole* point of Distribute 0.6.x is to be backward compatible, meaning
>> that if virtualenv switch to it, you will not even notice it.
>
> Living in my 0.6.x snail sandbox is not a solution.
> As it seem
Hi tarek,
Tarek Ziadé a écrit :
> The *whole* point of Distribute 0.6.x is to be backward compatible, meaning
> that if virtualenv switch to it, you will not even notice it.
Living in my 0.6.x snail sandbox is not a solution.
As it seems that Distribute 0.7 won't for a long time.
"setuptools ba
Lennart Regebro a écrit :
> 2009/10/9 Tarek Ziadé :
>> The *whole* point of Distribute 0.6.x is to be backward compatible, meaning
>> that if virtualenv switch to it, you will not even notice it.
>
> I guess the point is that is should still work even if you don't want
> to switch to distribute?
>
On Fri, Oct 9, 2009 at 2:36 PM, Lennart Regebro wrote:
> 2009/10/9 Tarek Ziadé :
>> The *whole* point of Distribute 0.6.x is to be backward compatible, meaning
>> that if virtualenv switch to it, you will not even notice it.
>
> I guess the point is that is should still work even if you don't want
2009/10/9 Tarek Ziadé :
> The *whole* point of Distribute 0.6.x is to be backward compatible, meaning
> that if virtualenv switch to it, you will not even notice it.
I guess the point is that is should still work even if you don't want
to switch to distribute?
--
Lennart Regebro: Python, Zope, P
On Thu, Oct 8, 2009 at 6:40 PM, Zooko Wilcox-O'Hearn wrote:
>
> What we do in the Tahoe-LAFS project is we don't count down to a future
> version, we only count up from a past version. This is also what Twisted
> does (no coincidence -- we probably got the idea from them).
To clarify: that means
On Fri, Oct 9, 2009 at 1:03 PM, Chris Withers wrote:
> Sridhar Ratnakumar wrote:
>>
>> This release includes a new packaging tool by activestate called Python
>> Package Manager (PyPM).
>
> Is PyPM available separately?
I had been asked for pre-release feedback on PyPM and suggested to
work on th
2009/10/9 Tarek Ziadé :
> I think the word "fork" here, in DVCS principles, just means that you
> copy a repository
> to work with, and eventually ask for the main repo to merge the changes.
Yeah, it's just a branch, basically. But it is hard to get an overview.
--
Lennart Regebro: Python, Zope
Chris Withers writes:
> Why are there effectively 3 forks on virtualenv now, just to get it to
> use distribute? Is it really so hard to work with Ian Bicking to be
> the real virtualenv using distribute instead of setuptools, especially
> in the way of the bdfl pronouncement?
You do realise tha
On Fri, Oct 9, 2009 at 2:03 PM, kiorky wrote:
> AND no, virtualenv must continue to provide setuptools, backward
> compatibility,
> you know?
The *whole* point of Distribute 0.6.x is to be backward compatible, meaning
that if virtualenv switch to it, you will not even notice it.
Tarek
_
Hi Chris,
As far as i know, we just give links for power users/developers to know how to
find the actual related repositories.
It s *CLEARLY* specified *IN THE HOMEPAGE METADATA* that the official thing
lives inside florian branch. Those are not 3 forks, but 3 branches or the same
code. And the fl
On Fri, Oct 9, 2009 at 1:07 PM, Chris Withers wrote:
> Reinout van Rees wrote:
>>
>> - Do my libraries have to list a dependency on distribute or on
>> setuptools?
>> Everything zopish has a 'setuptools >= 0.6c9' in it.
>
> They shouldn't, unless you only require setuptools after your package is
Chris Withers kirjoitti:
Tarek Ziadé wrote:
1- we ship 0.7 under a new name - e.g. like "distribute2"
You could even take the opportunity to rename it completely to
something that makes sense ;-)
While I agree that the name was badly chosen (for reasons you outline
below), a name change at
On Fri, Oct 9, 2009 at 12:54 PM, Chris Withers wrote:
> kiorky wrote:
>>
>> Hi Lennart,
>>
>> If i read 'virtualenv-distribute 1.3.4.2 on pypi'
>> I can do some googling or even do some Pypi searching for
>> 'virtualenv-distribute'.
>>
>> Thus, the first link found may be [1].
>>
>> On this link
2009/10/9 Chris Withers :
> Why are there effectively 3 forks on virtualenv now, just to get it to use
> distribute? Is it really so hard to work with Ian Bicking to be the real
> virtualenv using distribute instead of setuptools
Well I would expect Ian to want to take it a bit easy with the switc
On Fri, Oct 9, 2009 at 1:17 PM, Chris Withers wrote:
> Tarek Ziadé wrote:
>>
>> 1- we ship 0.7 under a new name - e.g. like "distribute2"
>
> You could even take the opportunity to rename it completely to something
> that makes sense ;-)
>
> To re-iterate my argument: Distribute doesn't distribute
Sridhar Ratnakumar wrote:
This release includes a new packaging tool by activestate called Python
Package Manager (PyPM).
Is PyPM available separately?
Here's a sample command line output::
$ pypm install lxml
Where does this get lxml from?
How can I control that?
Where does this put
Tarek Ziadé wrote:
1- we ship 0.7 under a new name - e.g. like "distribute2"
You could even take the opportunity to rename it completely to something
that makes sense ;-)
To re-iterate my argument: Distribute doesn't distribute anything. If
anything was to be called Distribute, it'd be the
Ian Bicking wrote:
I can imagine adding a little information, basically a log of when and
why and who installed the package. For instance:
agent: pip 0.5
install-date: 2009-10-08T13:44:00UTC
installed-for-user: False
installed-for-package: OtherPackage==0.3
I think this is a great i
Reinout van Rees wrote:
- Do my libraries have to list a dependency on distribute or on setuptools?
Everything zopish has a 'setuptools >= 0.6c9' in it.
They shouldn't, unless you only require setuptools after your package is
installed and don't use it in your setup.py, which seems unlikely.
Reinout van Rees wrote:
I'm still not 100% sure whether it is safe to put "distribute" in the
install_requires list of a package right now, however.
As with setuptools, why do you think you need to?
Chris
___
Distutils-SIG maillist - Distutils-SI
kiorky wrote:
Hi Lennart,
If i read 'virtualenv-distribute 1.3.4.2 on pypi'
I can do some googling or even do some Pypi searching for
'virtualenv-distribute'.
Thus, the first link found may be [1].
On this link, the second sentence is:
"""
The fork was started by Philip Jenvey at
http://bi
2009/10/8 Carl Meyer :
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Gediminas Paulauskas wrote:
>> Debian's Apt has this capability, see
>> https://wiki.ubuntu.com/PackageDependencyManagement . It keeps a
>> separate file to track the manually installed packages, and the flag
>> is named "
75 matches
Mail list logo