On 6/5/05, Phillip J. Eby [EMAIL PROTECTED] wrote:
At 04:40 PM 6/5/2005 +0100, Paul Moore wrote:
Is there a way of asking EasyInstall what packages are installed?
Not the command-line script. However ls site-packages/*.egg or dir
site-packages\*.egg depending on your platform will give you
I've just had a look at the new documentation for setuptools. I've not
read it all in detail yet, but one thing struck me regarding the
automatically download dependencies feature.
It isn't going to work for people (like me) stuck behind a firewall
that Python doesn't support (Windows NTLM based
Ian Bicking [EMAIL PROTECTED] writes:
I don't know how easy pycurl is to install -- I wonder in practice
if command-line interaction with curl would be easier to get people
to install (pycurl doesn't appear to have up-to-date windows
installers).
I was certainly just thinking of being able
Ryan Tomayko [EMAIL PROTECTED] writes:
One thing you could do is keep a bunch of eggs, .tar.gz's, exe's,
whatever in a directory on a web server with directory indexes turned
on and then add that page to the find_links options in you
~/.pydistutils.cfg file.
That's pretty neat. It's
On 7/12/05, Phillip J. Eby [EMAIL PROTECTED] wrote:
At 08:54 PM 7/11/2005 +0100, Paul Moore wrote:
Ah, there's the difficulty, of course :-) That's where a utility to
report the dependencies would help... (It may be pretty trivial, but I
don't see immediately how to do this - it seems to me
On 7/12/05, Phillip J. Eby [EMAIL PROTECTED] wrote:
At 10:32 PM 7/11/2005 +0100, Paul Moore wrote:
2. It would be useful if the -f option worked with a file: URL (or
better still, a simple directory name), to handle local
repositories.
A good idea, which I've been thinking about
On 7/12/05, Phillip J. Eby [EMAIL PROTECTED] wrote:
At 11:11 AM 7/12/2005 +0100, Paul Moore wrote:
Quick question, is there a convert but don't install yet option? So
I get an egg on my PC, but not in site-packages.
Yes, it's called --install-dir, and you set it to the directory where you'd
On 7/12/05, Kevin Dangoor [EMAIL PROTECTED] wrote:
easy_install -U setuptools
is the easiest way to upgrade. And, once you have the new version, you
will be able to do python -m easy_install -U setuptools to keep up to
date.
That conflicts with a bdist_wininst installation. Shouldn't be
I have been looking at how I can use eggs to manage the packages I currently
use in my Python installation. Mostly, everything has gone extremely smoothly,
and I can build eggs either from bdist_wininst executables, or from source
packages, without any problems (and without needing to modify the
I have only one egg installed in my site-packages, namely setuptools.
However, with the following script:
import sys
import pkg_resources
def list_packages():
dists = []
for p in sys.path:
for dist in pkg_resources.find_distributions(p):
dists.append((p, dist))
On 7/13/05, Paul Moore [EMAIL PROTECTED] wrote:
C:\Apps\Python24\lib\site-packages setuptools 0.5a12
C:\Apps\Python24\Lib\site-packages\setuptools-0.5a12-py2.4.egg setuptools
0.5a12
[...]
A complementary question - how can I detect when two Distribution
instances refer to the same egg
On 7/13/05, Phillip J. Eby [EMAIL PROTECTED] wrote:
At 11:20 AM 7/13/2005 +0100, Paul Moore wrote:
I can just say that users must install setuptools, but this seems ugly, as
there is no obvious reason why a date utility package should depend on a
setup
utility package.
I think you're
On 7/13/05, Phillip J. Eby [EMAIL PROTECTED] wrote:
At 03:00 PM 7/13/2005 +0100, Paul Moore wrote:
On 7/12/05, Paul Moore [EMAIL PROTECTED] wrote:
Given a Distribution object (maybe derived from a user's command line,
maybe from selection off a GUI) I can uninstall the Distribution by
simply
On 7/14/05, Phillip J. Eby [EMAIL PROTECTED] wrote:
At 11:26 AM 7/14/2005 +0100, Paul Moore wrote:
Hmm, I'm only looking on sys.path - I hadn't imagined that development
software would be added to the *default* sys.path...
By default, if you use develop on a package, it becomes part
On 8/11/05, Phillip J. Eby [EMAIL PROTECTED] wrote:
And without those signatures, your hand-installation procedure provides you
with *zero* additional security unless you're personally inspecting every
single line of code you install. Heck, you're running downloaded .exe
files with unsigned
On 9/17/05, Phillip J. Eby [EMAIL PROTECTED] wrote:
However, after reflection, I think now that -m probably only really makes
sense for stdlib modules, since projects using setuptools can now get all
the benefits of -m without any of the drawbacks, without even writing any
__name__=='__main__'
On 10/11/05, M.-A. Lemburg [EMAIL PROTECTED] wrote:
Only in the sense that it would require reinventing them in a different
form. :)
Not really - but we seem to have different views on whether
installers are good thing or not, so there's little point in
argueing over this.
I have to say
On 10/11/05, Phillip J. Eby [EMAIL PROTECTED] wrote:
At 04:56 PM 10/11/2005 +0100, Paul Moore wrote:
But for general packages (PIL, pywin32, cx_Oracle, whatever), I
actively want a managed installation. I have made noises about
building management tools for eggs, but I think I've been hitting
On 8/27/05, Martin v. Löwis [EMAIL PROTECTED] wrote:
I'm happy to announce the first beta release of my long-planned
distutils command bdist_msi, at
http://www.dcl.hpi.uni-potsdam.de/home/loewis/bdist_msi/
http://www.dcl.hpi.uni-potsdam.de/home/loewis/bdist_msi/bdist_msi-1.0b1.win32-py2.4.msi
On 11/17/05, Phillip J. Eby [EMAIL PROTECTED] wrote:
That's certainly part of it; but it's certainly not all of it. Mostly,
it's the difference between being a tool and a framework. The distutils
provides all the mechanism you like, and none of the policy. That was a
brilliant political
On 11/22/05, M.-A. Lemburg [EMAIL PROTECTED] wrote:
Actually loading the module then requires decompressing
the code which takes a whole lot longer than just reading
a file from the file system.
In summary, things get slower when importing from ZIP files;
it really only makes sense for
On 11/23/05, Phillip J. Eby [EMAIL PROTECTED] wrote:
Actually, I think the better long-term approach is more likely to be tools
like easy_deb that wrap easy_install. Better here meaning that it can
save the system packager work, because it can handle finding and fetching
and building in an
On 11/25/05, Vincenzo Di Massa [EMAIL PROTECTED] wrote:
To me, this sucks. Sorry, Philip, I know *why* you can't introspect a
non-egg ElementTree well enough to avoid this, but it still sucks.
Please read
http://mail.python.org/pipermail/distutils-sig/2005-November/005520.html
On 11/25/05, Donovan Baarda [EMAIL PROTECTED] wrote:
Sorry... that's what I meant; don't deb an egg... install it as an egg,
outside of the Debian package management system. As an egg, it is under
development and not ready for release as a deb. When the software is
ready for release, strip the
On 11/27/05, Ian Bicking [EMAIL PROTECTED] wrote:
easy_install --already-provided=1.2.6 ElementTree
that will create a .egg-info directory.
[Windows POV, so I removed the Debian crossposts]
Hmm, but what if I then upgrade (uninstall install a new version)
ElementTree? The egg dependency
On 12/19/05, Phillip J. Eby [EMAIL PROTECTED] wrote:
At 04:59 PM 12/19/2005 +0100, Daniel Glöckner wrote:
FYI, the shortest path to using MinGW with distutils or setuptools is to
run this script and follow its directions:
http://mail.python.org/pipermail/python-dev/2004-January/041676.html
On 12/22/05, M.-A. Lemburg [EMAIL PROTECTED] wrote:
Ian Bicking wrote:
I'm still finding it impossible to use multiple versions of a package
unless none of them show up in a .pth file (i.e., none are available
without requiring), I get a VersionConflict.
This comes up every now and then
On 2/9/06, Michael Twomey [EMAIL PROTECTED] wrote:
Hi,
Joe Gregorio has a fairly negative experience with easy_install here:
http://bitworking.org/news/Please_stop_using_setuptools__at_least_exclusively__for_now
I think his points boil roughly down to these:
[...]
5. At this point he
On 4/10/06, Phillip J. Eby [EMAIL PROTECTED] wrote:
Hm. That seems odd. It should just install itself. Have you tried
running ez_setup.py --allow-hosts=None -f. setuptools?
I tried -f . but missed --allow-hosts=None. No time to try it right
now, but I'll give it a go later. (Just for
On 6/28/06, Phillip J. Eby [EMAIL PROTECTED] wrote:
I assume that most people will read the docs on the web, and that if they
want the documentation source, they will download the sdist distribution
that I always upload alongside of the eggs.
I work offline sufficiently often that not having
On 6/29/06, Phillip J. Eby [EMAIL PROTECTED] wrote:
Note that I said above that I always put the documentation in an sdist
form;
Noted. The distinction I'm trying to make is that with bdist_wininst,
it's part of the binary installer - a single install gets the module
and its documentation, with
If I try to build a bdist_msi installer for a trivial module, using
Python 2.5b1, I get an error.
It looks like a problem with the interaction of the new (in 2.5)
egg-info stuff and the bdist_msi code - but I have no further ideas.
Here is the setup.py
from distutils.core import setup
setup(
On 6/29/06, Phillip J. Eby [EMAIL PROTECTED] wrote:
At 04:13 PM 6/29/2006 +0100, Paul Moore wrote:
Agreed. But in the absence of a standard, supporting package authors'
existing approaches, which work with other distutils mechanisms, seems
like a reasonable requirement.
Anything
I have now submitted a bug (http://www.python.org/sf/1515998).
Paul.
___
Distutils-SIG maillist - Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig
On 9/12/06, Phillip J. Eby [EMAIL PROTECTED] wrote:
Actually, that's not the reason. Python 2.5 requires setuptools 0.7a1,
which is only available from SVN.
Ah. In that case, the error is misleading but at least the solution is
straightforward :-) But I built and installed 0.6c2 as a
On 9/12/06, Phillip J. Eby [EMAIL PROTECTED] wrote:
At 10:19 PM 9/12/2006 +0100, Paul Moore wrote:
ez_setup won't install with Python 2.5c1 - presumably, because there
isn't a Python 2.5 egg available from the Cheeseshop. I'd have
expected it to build from sources in the absence of a suitable
On 9/17/06, John J Lee [EMAIL PROTECTED] wrote:
On Sat, 16 Sep 2006, Phillip J. Eby wrote:
Windows is probably the main offender, here, however, and I'm not sure
there's really a good solution there. I don't think there's a standard
$PATH directory that really makes sense for all
On 9/17/06, Phillip J. Eby [EMAIL PROTECTED] wrote:
At 02:38 PM 9/17/2006 +0100, Paul Moore wrote:
BTW, if you really want to make easy_install.exe available on the
command line without needing a PATH entry, you can do what python.exe
does: create a registry key
HKLM\Software\Microsoft
On 9/17/06, Phillip J. Eby [EMAIL PROTECTED] wrote:
I think getting a workable command-line environment on Windows without
end-user customization is an exercise in futility. :(
Agreed. That's where I came in :-)
Paul
___
Distutils-SIG maillist -
On 10/4/06, Phillip J. Eby [EMAIL PROTECTED] wrote:
At 11:12 PM 10/3/2006 +0100, Paul Moore wrote:
Also, the automatic pause would annoy me. How would you make it *not*
happen if I ran the command from a console window I already had open?
The idea would be to register a separate easy_install
On 10/4/06, Phillip J. Eby [EMAIL PROTECTED] wrote:
Okay, I've looked at the registry a bit, and it seems like I can register
App Paths either under HKLM (for the whole machine) or under HKCU (for the
current user). However, both seem to have issues.
[...]
2. Register HKCU App Paths entries
On 10/4/06, Phillip J. Eby [EMAIL PROTECTED] wrote:
Ah crap. I wonder if there's any way to tell whether you're the only
process on a particular console? That would fix this, I guess. There's a
GetConsoleProcessList() API, but it doesn't even work on Win2K as far as I
can tell; a minimum of
On 11/9/06, Thomas Heller [EMAIL PROTECTED] wrote:
It looks like all the information that is needed to implement the above
two features - is there a reason why this isn't implemented?
I believe it's simply a lack of time. Phillip has talked about
implementing a nest command to manage eggs, but
On 19/01/07, Howard Lightstone [EMAIL PROTECTED] wrote:
I am unable to rebuild things using disutils using Visual Studio
2005. I get reports of No compiler found.
Since VC8 is the only thing available in the future (from
Micro$soft), is there any progress toward updating distuils to
allow
On 02/02/07, Michael Foord [EMAIL PROTECTED] wrote:
Fair enough, I wasn't aware of this. I *have* heard reports of problems
for certain projects caused by extensions built with gcc on windows, but
they seemed like corner cases. (One was a database project which passed
file handles to the CRT -
On 02/02/07, Michael Foord [EMAIL PROTECTED] wrote:
Paul Moore wrote:
But, IIUC there can still be issues with using gcc for extensions -
because you are still using a different CRT layer and this can cause
problems.
Not true. When using mingw/gcc, distutils ensures that msvcr71.dll is
used
On 07/02/07, Jorge Vargas [EMAIL PROTECTED] wrote:
yes that's true the problem comes when you need windows.h or other
file that the mingw people can't distribute.
Um, windows.h comes with mingw - it's in the win32api package. (Which
doesn't alter the fact that MySQL may not support being
On 15/03/07, Howard Lightstone [EMAIL PROTECTED] wrote:
I have some (minor ?) changes to msvccompiler.py to support VC8 (and
embedding manifests).
Where should I submit these changes for someone (knowledgable) to review?
You should submit them as a patch to the Python patch tracker on
If I have a module which installs some files using the
data_files=[...] argument to setup.py, how do I then (reliably) find
those files from my code?
The first question is, is there a way of obtaining the distutils
data_files parameter value at runtime? If not, I guess I have to code
the same
On 14/01/2008, Phillip J. Eby [EMAIL PROTECTED] wrote:
At 11:24 AM 1/14/2008 +, Paul Moore wrote:
If I have a module which installs some files using the
data_files=[...] argument to setup.py, how do I then (reliably) find
those files from my code?
You can't. Use package_data instead
This is a dumb question, but I can't find the answer in the
easy_install documentation (I have to say, I always find that page
hard to follow...)
How do I use easy_install to just locate and download an egg (not install it)?
Suppose I have a directory eggs and I want to grab a batch of eggs
from
On 04/03/2008, Phillip J. Eby [EMAIL PROTECTED] wrote:
easy_install -zmaxd targetdir ...
Thanks. I see it in the documentation now. Sorry I missed it.
Paul.
___
Distutils-SIG maillist - Distutils-SIG@python.org
On 17/03/2008, Phillip J. Eby [EMAIL PROTECTED] wrote:
The PEP suggests that other package managers also benefit. How do they
benefit if the bootstrap script installs setuptools?
Because those other package managers depend, in fact, on setuptools,
or at least pkg_resources... which was why
On 17/03/2008, Martin v. Löwis [EMAIL PROTECTED] wrote:
Personally, I have no problem per se with including setuptools in the
stdlib. Maybe that means I miss the subtle benefit of this approach...
Did you review setuptools and can vouch that it is written cleanly,
follows the coding style,
On 17/03/2008, Guido van Rossum [EMAIL PROTECTED] wrote:
On Mon, Mar 17, 2008 at 11:55 AM, Stefan Behnel [EMAIL PROTECTED] wrote:
Is it *wanted* that eggs are being supported by core Python?
No. There will be no egg support in the standard library.
This bothers me somewhat. At a certain
On 18/03/2008, Marius Gedminas [EMAIL PROTECTED] wrote:
+1 for something like this in the stdlib.
os.path.join(os.path.dirname(__file__), 'foo') just has too many
problems.
Hmm, maybe I should put some of my money where my mouth is. I'd be
willing to work up a patch to add some key items
On 18/03/2008, Phillip J. Eby [EMAIL PROTECTED] wrote:
Sure... though I doubt you'll have much luck, unless you drop
support for resource_filename, and stick with
resource_string()/resource_stream(). Supporting resource_filename()
for zipfiles inherently requires that you extract the file
On 19/03/2008, Jeff Rush [EMAIL PROTECTED] wrote:
1. What is the plan for PyPI when Python 3.0 comes out and
dependencies start getting satisfied from distribution
across the great divide, e.g. a 3.0-specific package
pulls from PyPI a 2.x-specific package to meet some
need?
On 19/03/2008, Phillip J. Eby [EMAIL PROTECTED] wrote:
I don't particularly want to use undocumented functions - even within
the module that defines them.
Er, you could always document them, you know. I just didn't get
around to it before the whole setuptools flap of 2005 wiped out my
On 19/03/2008, Guido van Rossum [EMAIL PROTECTED] wrote:
On Mon, Mar 17, 2008 at 2:19 PM, zooko [EMAIL PROTECTED] wrote:
4. The standard Python library includes a tool to find and read
resources (other than Python modules) that came bundled in a Python
package.
I think we're pretty
On 20/03/2008, zooko [EMAIL PROTECTED] wrote:
On Mar 19, 2008, at 3:23 PM, Guido van Rossum wrote:
If other people want to chime in please do so; if this is just a
dialog between Phillip and me I might incorrectly assume
that nobody besides Phillip really cares.
I really care. I've
On 20/03/2008, Jeff Rush [EMAIL PROTECTED] wrote:
Paul Moore wrote:
On 20/03/2008, zooko [EMAIL PROTECTED] wrote:
1. No integration with the system packager (Windows, in my case). If I
do easy_install nose, then nose does not show up in add/remove
programs. That significantly affects
On 20/03/2008, Phillip J. Eby [EMAIL PROTECTED] wrote:
Actually, this information is VERY helpful. It makes it blindingly
obvious to me now that the difference between loving and hating
setuptools is whether you're *intentionally* using it, or whether it
shows up in your ecosystem
On 21/03/2008, Phillip J. Eby [EMAIL PROTECTED] wrote:
Questions, comments... volunteers? :)
Sounds good. I won't volunteer as I have neither time nor expertise to
contribute much. But I'd like to see this happen, as it sounds like it
would address all my issues with setuptools (and just to
On 22/03/2008, Steve Holden [EMAIL PROTECTED] wrote:
Well, I've probably been killfiled into non-existence on this list by
now, but it seems to me that we are in danger of answering the wrong
problem yet again. But that's all I have to say on this topic, so you
can all heave a sigh a relief
On 22/03/2008, Alexander Michael [EMAIL PROTECTED] wrote:
IOW, the PEP is lacking a rationale.
It seems to me that this discussion is being undermined by not
acknowledging the many use cases up front. There is no rationale
because there are too many tacit rationales.
Absolutely! It
On 22/03/2008, Martin v. Löwis [EMAIL PROTECTED] wrote:
How would you install multiple versions in the first place? Python
supports no such thing, at least not without setting PYTHONPATH,
or otherwise changing sys.path.
That's an unrelated feature of setuptools, providing a way to
install
On 22/03/2008, Phillip J. Eby [EMAIL PROTECTED] wrote:
This probably needs to be refined a little. Exclusive right is too
strong, and it goes against Paul Moore's desire for using a single
tool.
Huh? How's that? Don't forget that I'm on Windows, and on Windows
there is no system tool - just
On 22/03/2008, Martin v. Löwis [EMAIL PROTECTED] wrote:
Oh, and application installation is (should be) completely different.
On Windows, applications should probably be bundled with their own
Python interpreter, a la py2exe. On Unix/Linux, I don't know what the
standard is, so I'd have
On 08/04/2008, zooko [EMAIL PROTECTED] wrote:
By the way, since I posted my proposal two weeks ago I have pointed a
couple of Python hackers who currently refuse to use eggs at the URL:
http://mail.python.org/pipermail/python-dev/2008-March/078243.html
They both agreed that it made
On 09/04/2008, Stanley A. Klein [EMAIL PROTECTED] wrote:
IMHO, the main system without a package manager is Windows. A reasonable
way to deal with Windows would be to create a package manager for it that
could be used by Python and anyone else who wanted to use it. The package
manager
On 09/04/2008, Stanley A. Klein [EMAIL PROTECTED] wrote:
I think you raise an interesting issue: What is a package manager?
My (very simplistic) answer is that it's whatever someone uses to
manage packages. What level of functionality it has is irrelevant, as
long as it suits an individual's
On 09/04/2008, Phillip J. Eby [EMAIL PROTECTED] wrote:
It would be, if .eggs were a packaging format, rather than a binary
distribution/runtime format.
Remember eggs are to Python as jars are to Java -- a Java .jar
doesn't contain documentation either, unless it's needed at
runtime.
On 09/04/2008, Ben Finney [EMAIL PROTECTED] wrote:
Stanley A. Klein [EMAIL PROTECTED] writes:
A reasonable way to deal with Windows would be to create a package
manager for it that could be used by Python and anyone else who
wanted to use it. [...] This is primarily a Windows problem, not
For me, on Windows, the biggest negative aspect of eggs is when people
provide binary installations (ones with compiled C extensions) in eggs
only. I prefer bdist_wininst/bdist_msi installers, and with compiled
code, I can't always build from source (complex library dependencies,
etc).
So, given
On 10/04/2008, Phillip J. Eby [EMAIL PROTECTED] wrote:
At 09:10 AM 4/10/2008 +0100, Paul Moore wrote:
So, given that an egg already has everything that is needed at
runtime, how easy would it be to create a tool which converted an egg
into a bdist_wininst installer? With that, I could
On 19/03/2008, Guido van Rossum [EMAIL PROTECTED] wrote:
I'm currently working on an addition to pkgutil to provide this type
of function. I'm considering going a little further (adding functions
to get a file-like object, test for existence, and list available
resources, modelled on
2008/5/8 Jeff Rush [EMAIL PROTECTED]:
Note that the trailing slash is NOT optional. For now the tracker echoes
bug reports onto the distutils list, for community awareness. If this turns
out to be a problem, I'll create a separate distutils-bugs list but wanted
to avoid having folks sign up
2008/10/6 Phillip J. Eby [EMAIL PROTECTED]:
At 12:05 PM 10/6/2008 -0700, Chris Mahan wrote:
Phillip,
At
http://pypi.python.org/pypi/setuptoolshttp://pypi.python.org/pypi/setuptools
there is no MS windows installer for python 2.6.
Do you have an idea of when that might be available?
No,
2008/10/7 Phillip J. Eby [EMAIL PROTECTED]:
This is a really frustrating aspect of setuptools, that pure-Python
packages produce version-specific installers.
Actually, that's not setuptools' fault in this case; I specifically make the
.exe's version-specific because they have different
2008/10/7 Phillip J. Eby [EMAIL PROTECTED]:
In the case of BUILDS, I propose to do the same: define a standard whose
cost/benefit ratios are ideally balanced for each participant. This does
not, by the way, mean that everybody ends up with the same cost/benefit
ratio; it simply means that the
2008/10/7 Phillip J. Eby [EMAIL PROTECTED]:
At 10:04 AM 10/7/2008 +0100, Paul Moore wrote:
2008/10/7 Phillip J. Eby [EMAIL PROTECTED]:
You can see that this is also what I did in the design of easy_install
and
setuptools, except that in that effort I only considered developers and
users
2008/10/10 Ian Bicking [EMAIL PROTECTED]:
Paul Moore wrote:
My feeling, by the way, is that system packagers are the more
relevant group on Linux/Unix (where most users install Python modules
via system packages, or else they are developers)
I think this is part of why I don't understand
I see that there's a Win32 egg for setuptools for Python 2.6, but no
bdist_wininst style installer. Will a bdist_wininst installer be
provided? When is it likely to be available?
Paul.
___
Distutils-SIG maillist - Distutils-SIG@python.org
2008/10/17 Barry Warsaw [EMAIL PROTECTED]:
So once again, I think this boils down to these questions: if we have a
small library whose sole purpose is to abstract a data store so you can
find out where a particular non-code file lives on this system will you
use it?
I would. I apologize for
The setuptools download page says that you should install setuptools
from the provided .exe file on Windows. However, for Python 2.6, there
is only a .egg file. Where should I go to get a Python 2.6 setuptools
.exe installer?
Thanks,
Paul.
___
2008/12/23 Phillip J. Eby p...@telecommunity.com:
At 10:11 AM 12/23/2008 -0500, Rocky Bernstein wrote:
This is useful information and thanks for suggesting the workaround.
However this does not address the issue which is not about how I can
create an unzipped egg for my use or the use of
2009/2/2 David Cournapeau da...@ar.media.kyoto-u.ac.jp:
I never said it was self-evident. And about the part of determining what
the right place is: the whole point is that you, as a developer, won't
have to care :) Only by changing the distutils implementation and adding
some options to the
2009/2/14 Tarek Ziadé ziade.ta...@gmail.com:
I really like the way setuptools wraps scripts depending on the platform.
http://peak.telecommunity.com/DevCenter/setuptools#automatic-script-creation
I am not talking about the entry_point feature, but the way it creates
executables.
What would
2009/3/9 Tarek Ziadé ziade.ta...@gmail.com:
Thanks to all the people that helped building the survey, and a
special thanks to Massimo Di Pierro who created the application that
runs the Survey and helped me set it up.
Please, take it !
http://tinyurl.com/package-survey
I get a page load
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
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
2009/4/9 Lennart Regebro rege...@gmail.com:
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
2009/4/9 zooko zo...@zooko.com:
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
2009/4/9 Lennart Regebro rege...@gmail.com:
2009/4/9 Paul Moore p.f.mo...@gmail.com:
Don't they? I have to admit that I'm baffled by how the features in
setuptools/eggs/easy_install all hang together. What about the magic
that creates executables from scripts? Entry points? Stuff like
2009/4/9 David Cournapeau da...@ar.media.kyoto-u.ac.jp:
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
2009/4/9 Lennart Regebro rege...@gmail.com:
2009/4/9 Paul Moore p.f.mo...@gmail.com:
Personally, I'd be happy if every package that currently distributes
any form of Windows binaries, distributed a Windows installer. That's
about the same level of coverage as existed before setuptools
2009/4/9 Thomas Heller thel...@ctypes.org:
Is there a technical reason why Windows users cannot build the
installers themselves from pure Python sdists?
No. There's even a script that automates the process completely. It allows
to build bdist_wininst installers by drag and drop.
2009/4/9 Tres Seaver tsea...@palladion.com:
However, it's equally true (I believe) that python setup.py
bdist_wininst works fine on a Linux box. So it's not as if building
Windows installers is a huge chore for developers, either. (I accept
that there are other tasks, like distribution). It's
2009/4/9 Tres Seaver tsea...@palladion.com:
creating dist
Warning: Can't read registry to find the necessary compiler setting
Make sure that Python modules _winreg, win32api or win32con are installed.
This is a warning, so can be ignored.
error:
1 - 100 of 1365 matches
Mail list logo
