We are talking about the "preferred" default archive format in Distutils-SIG.
I was wondering if you could give us some statistics on the various
archives format used at PyPI.
Tarek Ziadé | http://ziade.org
Michael reported that sdist produces a zip file under windows and a
tar file under posix by default, which is inconsistent.
I've changed the sdist command some time ago, so it uses the sdtilb
tarfile module, instead of the "tar" command,
meaning that we could switch to the tar format under windows by
default as well now, not requiring the "tar" program anymore
But some people may prefer the zip format.
What are your opinion on this ?
You can respond here, or in the issue we have created
Tarek Ziadé | http://ziade.org
While I was reading this PEP, I noticed that it suggests the '-'
character as separator (between name, version, etc..) .. naturally
introducing '_' *within* names and versions.
This decision looks odd to me, as several package systems I know of use
the '_' character as seperator. In Debian,
Besides, it is very common for Python packages to use '-' in their names
instead of '_'.
[.. pypimirror]$ ls | grep "_" | wc -l
[.. pypimirror]$ ls | grep "-" | wc -l
Why not use '_' as separator?
Hello. Could you please tell me what your schedule is for
upgrading setuptools and easy_install to support Python 3?
Do you know what version of those packages will support
Python 3, and about what timeframe?
Andreas Jung wrote:
> it is known that the latest setuptools version produces broken
> packages with SVN 1.6 checkouts. Could we get a fixed setuptools
> version asap - fixing this issue is essential
> (there is some patch floating around).
I think you meant this to go to the distutils sig...
Simplistix - Content Management, Zope & Python Consulting
At 12:47 PM 6/17/2009 +0100, Dave Pawson wrote:
>[root@marge2 python]# ./setuptools-0.6c9-py2.6.egg
>error: invalid Python installation: unable to open
>/usr/lib/python2.6/config/Makefile (No such file or directory)
This means you don't have the python-dev or python-devel package
installed on your system. Some OS distributors actually split Python
into two packages, and you can't run the distutils properly without
the second one.
>on Fedora core 11.
You can probably also just install the Fedora package for setuptools.
I downloaded setuptools-0.6c9-py2.6.egg
as root, chmod +x setup...
ran it and received:
[root@marge2 python]# ./setuptools-0.6c9-py2.6.egg
error: invalid Python installation: unable to open
/usr/lib/python2.6/config/Makefile (No such file or directory)
[dpawson@marge2 python]$ python --version
on Fedora core 11.
Any suggestions please, I'd like to use easy_install.
XSLT XSL-FO FAQ.
Relatively new to python (and very new to distutils) but experienced
I'm trying to do a 64 bit build of
I'm on Windows Server 2008 R2. First had to acquaint myself with
mingw32. That built but the DLLs (or rather PYDs) that are created
won't load at runtime. I transferred the build to a 32 bit machine; the
PYDs loaded; and the program ran successfully. Thus, as I said, I'm
looking to rebuild in 64 bits.
It's seems that there's a 64 bit version of mingw in development on
sourceforge: http://sourceforge.net/projects/mingw-w64. You download a
toolchain; add that to your Windows PATH; and I'm able to build a
sample hello.c successfully.
The problem is with Python and setup.py. When I try to specify compiler
i86_64-mingw32 or some variant to setup.py, I get the following:
> L:\pf\Python\pyOpenSSL>setup.py build_ext -Ic:\openssl\include -c
> running build_ext
> error: don't know how to compile C/C++ code on platform 'nt' with
> 'x86_64-pc-mingw32' compiler
So after fumbling around a bit, where I've arrived at is that in the
distutils package ( c:\python26\lib\distutils ) there are various files
such as msvccompiler.py, msvccompiler9.py (I have VS 2008 installed),
ccompiler.py and cygwincompiler.py that would seem to indicate that
'new' compilers have to have support built into distutils.
Is this correct, and if so, how does one go about the task of adding a
thanx - pat
It may seem like a backwards way of doing things, but I have a need for
a utility that can maintain a python package index mirror of a Debian
The basic idea is to extract the tarballs of Python packages from the
Debian repository and rename them to the original setuptools name. It
should also create a buildout-compatible versions file of the versions
in the repository.
My current implementation idea is to unpack the tarball and use the
egg-metadata to figure out what the "egg" name of the tarball should be.
Does such a tool exists? If not, I'll probably start working on one on
svn.zope.org Real Soon Now (TM). Comments, suggestions much
At 01:38 PM 6/11/2009 -0700, Trent Mick wrote:
>- when I specify a dependency against a particular build_number of a
>package, I don't care if that build_number happened to be a released
>version or a dev version
However, to specify that dependency you're going to need a way to
represent the build number as part of a requirement string, at which
point we're right back where we started.