Lennart Regebro wrote:
On Wed, Apr 8, 2009 at 06:04, David Cournapeau
da...@ar.media.kyoto-u.ac.jp wrote:
It does if the underlying implementation is not shared correctly between
all the tools.
Since we are discussing what the underlying implementation to be
shared by all tools
On Tue, Apr 07, 2009 at 07:27:29PM +0200, Lennart Regebro wrote:
On Tue, Apr 7, 2009 at 19:12, Marius Gedminas mar...@pov.lt 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
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
requested, adds
On Wed, Apr 8, 2009 at 09:40, Marius Gedminas mar...@pov.lt 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.
--
On Wed, Apr 8, 2009 at 7:44 PM, Marius Gedminas mar...@pov.lt 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
On Tue, Apr 7, 2009 at 8:47 PM, Lennart Regebro rege...@gmail.com wrote:
On Tue, Apr 7, 2009 at 20:18, Tarek Ziadé ziade.ta...@gmail.com 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
On Wed, Apr 8, 2009 at 10:21, Tarek Ziadé ziade.ta...@gmail.com 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
2009/4/8 Ben Finney ben+pyt...@benfinney.id.au:
David Cournapeau da...@ar.media.kyoto-u.ac.jp 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
On Wed, Apr 8, 2009 at 10:30 AM, Lennart Regebro rege...@gmail.com wrote:
On Wed, Apr 8, 2009 at 10:21, Tarek Ziadé ziade.ta...@gmail.com 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
On Wed, Apr 8, 2009 at 12:06 PM, Lennart Regebro rege...@gmail.com 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
On Wed, Apr 8, 2009 at 12:03, Tarek Ziadé ziade.ta...@gmail.com 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
2009/4/8 Tarek Ziadé ziade.ta...@gmail.com:
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
On Wed, Apr 8, 2009 at 12:11 PM, Lennart Regebro rege...@gmail.com wrote:
On Wed, Apr 8, 2009 at 12:03, Tarek Ziadé ziade.ta...@gmail.com 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
On Wed, Apr 8, 2009 at 13:01, Tarek Ziadé ziade.ta...@gmail.com 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
-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
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Noah Gift wrote:
On Wed, Apr 8, 2009 at 7:44 PM, Marius Gedminas mar...@pov.lt 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
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 p.f.mo...@gmail.com wrote:
As a bystander, what *I* care most about is that Python ends up with a
single approach to creating and distributing
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Tarek Ziadé wrote:
On Tue, Apr 7, 2009 at 8:47 PM, Lennart Regebro rege...@gmail.com wrote:
On Tue, Apr 7, 2009 at 20:18, Tarek Ziadé ziade.ta...@gmail.com wrote:
If anyone wants to work on it, or comment,
Some comments:
MANIFEST.in is fine
On Wed, Apr 8, 2009 at 14:23, Tres Seaver tsea...@palladion.com 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
On Wed, Apr 8, 2009 at 11:48 AM, Paul Moore p.f.mo...@gmail.com wrote:
2009/4/8 Paul Moore p.f.mo...@gmail.com:
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
On Wed, Apr 8, 2009 at 2:23 PM, Tres Seaver tsea...@palladion.com wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Tarek Ziadé wrote:
On Tue, Apr 7, 2009 at 8:47 PM, Lennart Regebro rege...@gmail.com wrote:
On Tue, Apr 7, 2009 at 20:18, Tarek Ziadé ziade.ta...@gmail.com wrote:
If anyone
Tres Seaver wrote:
Tarek Ziadé wrote:
On Tue, Apr 7, 2009 at 8:47 PM, Lennart Regebro rege...@gmail.com
wrote:
On Tue, Apr 7, 2009 at 20:18, Tarek Ziadé ziade.ta...@gmail.com
wrote:
If anyone wants to work on it, or comment,
Some comments:
MANIFEST.in is fine
Except that it
At 02:33 PM 4/8/2009 +0200, Lennart Regebro wrote:
On Wed, Apr 8, 2009 at 14:23, Tres Seaver tsea...@palladion.com 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.
On 4/8/09 6:27 AM, Paul Moore wrote:
2009/4/8 Tarek Ziadé ziade.ta...@gmail.com:
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.
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
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?
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
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',
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'),
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
Paul Moore p.f.mo...@gmail.com 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
On Wed, Apr 8, 2009 at 23:37, Jason R. Coombs jar...@jaraco.com 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
On Wed, Apr 8, 2009 at 12:27, Paul Moore p.f.mo...@gmail.com 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
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 python
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-)
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
36 matches
Mail list logo
