I noticed when installing setuptools on Python 2.3 that easy_install
fails because it tries to import subprocess, which is a new module in
2.4. I personally do not need Python 2.3 support any longer, but the
docs say it should be supported, which seems to be only partly true.
The rest of setuptool
At 04:48 PM 4/8/2009 -0700, Sridhar Ratnakumar wrote:
On 08/04/09 02:53 PM, P.J. Eby wrote:
Something like this should do the trick:
import tempfile, os.path
from setuptools.sandbox import run_setup
def get_requires(setup_dir, empty_tmpdir):
tmpdir = tempfile.mkdtemp(prefix="egginfotmp-")
Ben Finney wrote:
>
> I presume, by “meta-requirement”, you're showing awareness that this
> is something very much dependent on motivating people to actually
> create those installers for each and every package.
>
Yes, and eggs decreases this motivation, as eggs are cross-platform (if
only pyt
On Wed, Apr 8, 2009 at 12:27, Paul Moore wrote:
> 1. (Meta-requirement) I want to be able to download a Windows
> installer[1] for *every* package I need.
I would like to know why you have this requirement. Some sort of
Windows binary, absolutely. But an installer? Would a package
management GUI
On Wed, Apr 8, 2009 at 23:37, Jason R. Coombs wrote:
> Lennart,
> That seems to have done the trick. Between that fix and using the
> 64-bit cli.exe and gui.exe from http://bugs.python.org/setuptools/issue2, I
> was able to install setuptools on Python 3.0.1 64-bit on Windows Vista SP1
> a
Paul Moore writes:
> 1. (Meta-requirement) I want to be able to download a Windows
> installer[1] for *every* package I need.
I presume, by “meta-requirement”, you're showing awareness that this
is something very much dependent on motivating people to actually
create those installers for each an
On Apr 8, 2009, at 4:27 AM, Paul Moore wrote:
1. (Meta-requirement) I want to be able to download a Windows
installer[1] for *every* package I need.
1a. This means that the barrier for packagers building Windows
installers should be as low as possible.
1b. It also means that other formats (e.
On 08/04/09 02:53 PM, P.J. Eby wrote:
Something like this should do the trick:
import tempfile, os.path
from setuptools.sandbox import run_setup
def get_requires(setup_dir, empty_tmpdir):
tmpdir = tempfile.mkdtemp(prefix="egginfotmp-")
run_setup(os.path.join(setup_dir,'setup.py'), ['-
At 01:28 PM 4/8/2009 -0700, Sridhar Ratnakumar wrote:
For example, zc.catalog declares these dependencies in its setup.py
install_requires=['ZODB3',
'pytz',
'setuptools',
'zope.catalog',
'zope.c
Lennart,
That seems to have done the trick. Between that fix and using the
64-bit cli.exe and gui.exe from http://bugs.python.org/setuptools/issue2, I
was able to install setuptools on Python 3.0.1 64-bit on Windows Vista SP1
and run easy_install. For that build in particular, a Windows i
Sridhar Ratnakumar wrote:
> Is it possible to get the value of install_requires for an arbitrary
> package without having to parse setup.py?
>
> I see that --name, --version, --description, --provides, and so on are
> available as an argument to setup.py, but --install-requires is missing.
> Why?
Is it possible to get the value of install_requires for an arbitrary
package without having to parse setup.py?
I see that --name, --version, --description, --provides, and so on are
available as an argument to setup.py, but --install-requires is missing.
Why?
For example, zc.catalog declares
On Wed, Apr 8, 2009 at 21:12, Jason R. Coombs wrote:
> Unfortunately, I'm not sure what negative impact would come from altering
> pkg_resources.DefaultProvider._get to always read bytes, and that doesn't
> strike me as the correct solution.
No, if you do that everything explodes, and you can't e
Thanks to Lennart Regebro for putting together a build of setuptools for
Python 3 here:
http://regebro.wordpress.com/2009/02/01/setuptools-and-easy_install-for-pyth
on-3/
Unfortunately, the package fails to build on Windows. Refer to the blog
post (and comments) for details.
The problem occurs w
On Wed, Apr 08, 2009 at 08:18:41AM -0400, Tres Seaver wrote:
> Noah Gift wrote:
> > On Wed, Apr 8, 2009 at 7:44 PM, Marius Gedminas wrote:
> >> On Tue, Apr 07, 2009 at 02:23:50PM -0400, Jim Fulton wrote:
> >>> My experience on Linux is that installing eggs as Zip files slows
> >>> imports.
> >> Wa
On 4/8/09 6:27 AM, Paul Moore wrote:
> 2009/4/8 Tarek Ziadé :
>>> Nobody seems to be attempting to collect requirements here.
>>>
>> I do, in the wiki. I am trying to synchronize the work done at Pycon, and
>> in the future. I am trying to synthethize the needs there.
>>
>> http://wiki.python.org/
At 02:33 PM 4/8/2009 +0200, Lennart Regebro wrote:
On Wed, Apr 8, 2009 at 14:23, Tres Seaver wrote:
> I want *less* stuff (ideally nothing) spelled in imperative Python, with
> some common declarative file replacing both the information currently in
> setup.py and MANIFEST.in. I thought we were
Tres Seaver wrote:
> Tarek Ziadé wrote:
> > On Tue, Apr 7, 2009 at 8:47 PM, Lennart Regebro
> wrote:
> >> On Tue, Apr 7, 2009 at 20:18, Tarek Ziadé
> wrote:
> >>> If anyone wants to work on it, or comment,
> >> Some comments:
> >>
> >>> "MANIFEST.in is fine"
> >> Except that it introduces Yet Ano
On Wed, Apr 8, 2009 at 2:23 PM, Tres Seaver wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Tarek Ziadé wrote:
>> On Tue, Apr 7, 2009 at 8:47 PM, Lennart Regebro wrote:
>>> On Tue, Apr 7, 2009 at 20:18, Tarek Ziadé wrote:
If anyone wants to work on it, or comment,
>>> Some comm
On Wed, Apr 8, 2009 at 14:23, Tres Seaver wrote:
> I want *less* stuff (ideally nothing) spelled in imperative Python, with
> some common declarative file replacing both the information currently in
> setup.py and MANIFEST.in. I thought we were in agreement that
> non-introspectable metadata was
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Tarek Ziadé wrote:
> On Tue, Apr 7, 2009 at 8:47 PM, Lennart Regebro wrote:
>> On Tue, Apr 7, 2009 at 20:18, Tarek Ziadé wrote:
>>> If anyone wants to work on it, or comment,
>> Some comments:
>>
>>> "MANIFEST.in is fine"
>> Except that it introduces
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Noah Gift wrote:
> On Wed, Apr 8, 2009 at 7:44 PM, Marius Gedminas wrote:
>> On Tue, Apr 07, 2009 at 02:23:50PM -0400, Jim Fulton wrote:
>>> On Apr 7, 2009, at 9:28 AM, P.J. Eby wrote:
At 11:54 PM 4/7/2009 +1200, Noah Gift wrote:
> 1. In the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Lennart Regebro wrote:
> There has been two related proposals afaik. Tareks talk about plugins,
> and mine where I said I would like the default behavior to be:
>
> 1. The file list is gotten from a specification in setup.py.
> 2. If no such specific
On Wed, Apr 8, 2009 at 13:01, Tarek Ziadé wrote:
> I don't think we want to break any current feature in 2.7, we will
> probably just display
> deprecation warnings and keep them, then wait until the next python version.
>
> And if someone want to use your package, that uses a new feature
> that i
On Wed, Apr 8, 2009 at 12:11 PM, Lennart Regebro wrote:
> On Wed, Apr 8, 2009 at 12:03, Tarek Ziadé wrote:
>> But I will not work in flame-threads anymore on my side.
>
> Probably a good idea.
>
> The only thing I'm worried about is the fact that you are proposing
> both to remove and add things
2009/4/8 Tarek Ziadé :
>> Nobody seems to be attempting to collect requirements here.
>>
>
> I do, in the wiki. I am trying to synchronize the work done at Pycon, and
> in the future. I am trying to synthethize the needs there.
>
> http://wiki.python.org/moin/DistutilsVersionFight
> http://wiki.pyt
On Wed, Apr 8, 2009 at 12:03, Tarek Ziadé wrote:
> But I will not work in flame-threads anymore on my side.
Probably a good idea.
The only thing I'm worried about is the fact that you are proposing
both to remove and add things to distutils. Although backports will be
available, how will this wo
On Wed, Apr 8, 2009 at 12:06 PM, Lennart Regebro wrote:
> There has been two related proposals afaik. Tareks talk about plugins,
> and mine where I said I would like the default behavior to be:
>
> 1. The file list is gotten from a specification in setup.py.
> 2. If no such specification, the file
Meta discussions are generally a complete waste of time. This is the
only thing I intend to say on the issue.
On Wed, Apr 8, 2009 at 11:44, Paul Moore wrote:
> As a bystander, what *I* care most about is that Python ends up with a
> single approach to creating and distributing extensions. What co
On Wed, Apr 8, 2009 at 10:30 AM, Lennart Regebro wrote:
> On Wed, Apr 8, 2009 at 10:21, Tarek Ziadé wrote:
>> I agree with this. Remember: I wanted to deprecate MANIFEST.in in favor of
>> a pure python description. Then people strongly objected.
>
> How many people objected? Would it be OK to onl
On Wed, Apr 8, 2009 at 11:48 AM, Paul Moore wrote:
> 2009/4/8 Paul Moore :
>> As a bystander, what *I* care most about is that Python ends up with a
>> single approach to creating and distributing extensions. What concerns
>> me most about this whole discussion, is that it seems like no-one is
>>
2009/4/8 Paul Moore :
> As a bystander, what *I* care most about is that Python ends up with a
> single approach to creating and distributing extensions. What concerns
> me most about this whole discussion, is that it seems like no-one is
> attempting to compromise, and participants are pulling fur
2009/4/8 Ben Finney :
> David Cournapeau writes:
>
>> Ok. Looks like you feel insulted for some reasons to keep insulting
>> me back. Since I can't make my point clearly, and nobody in this
>> discussion seems to care anyway, I will leave the discussion.
>
> I hope you can reconsider (but certainl
On Wed, Apr 8, 2009 at 10:21, Tarek Ziadé wrote:
> I agree with this. Remember: I wanted to deprecate MANIFEST.in in favor of
> a pure python description. Then people strongly objected.
How many people objected? Would it be OK to only have support for this
in an external plugin, and not in stdlib
On Tue, Apr 7, 2009 at 8:47 PM, Lennart Regebro wrote:
> On Tue, Apr 7, 2009 at 20:18, Tarek Ziadé wrote:
>> If anyone wants to work on it, or comment,
>
> Some comments:
>
>> "MANIFEST.in is fine"
>
> Except that it introduces Yet Another Domain Specific Language. Wtf
> does "prune" mean? It's n
On Wed, Apr 8, 2009 at 7:44 PM, Marius Gedminas wrote:
> On Tue, Apr 07, 2009 at 02:23:50PM -0400, Jim Fulton wrote:
>> On Apr 7, 2009, at 9:28 AM, P.J. Eby wrote:
>>> At 11:54 PM 4/7/2009 +1200, Noah Gift wrote:
1. In the case of entry points for setuptools, it actually recurses
into E
On Wed, Apr 8, 2009 at 09:40, Marius Gedminas wrote:
> Are we talking about the current design (which doesn't include
> everything), or about some proposed change?
Proposed change, of course. That the current situation is broken is
well established. Nobody is defending it.
--
Lennart Regebro: P
On Tue, Apr 07, 2009 at 02:23:50PM -0400, Jim Fulton wrote:
> On Apr 7, 2009, at 9:28 AM, P.J. Eby wrote:
>> At 11:54 PM 4/7/2009 +1200, Noah Gift wrote:
>>> 1. In the case of entry points for setuptools, it actually recurses
>>> into EVERY egg directory in your path, not just the egg you
>>> requ
On Tue, Apr 07, 2009 at 07:27:29PM +0200, Lennart Regebro wrote:
> On Tue, Apr 7, 2009 at 19:12, Marius Gedminas wrote:
> > Consider a different use case: my friend's friend Alice does not like
> > svn. She uses git-svn to get a local git repository containing a copy
> > of the subversion code.
David Cournapeau writes:
> Ok. Looks like you feel insulted for some reasons to keep insulting
> me back. Since I can't make my point clearly, and nobody in this
> discussion seems to care anyway, I will leave the discussion.
I hope you can reconsider (but certainly a little time away from the
d
40 matches
Mail list logo
