Hi all --
at long last, I have fixed two problems that a couple people noticed a
while ago:
* I folded in Amos Latteier's NT patches almost verbatim -- just
changed an `os.path.sep == "/"' to `os.name == "posix"' and added
some comments bitching about the inadequacy of the current library
installation model (I think this is Python's fault, but for now
Distutils is slavishly aping the situation in Python 1.5.x)
* I fixed the problem whereby running "setup.py install" without
doing anything else caused a crash (because 'build' hadn't yet
been run). Now, the 'install' command automatically runs 'build'
before doing anything; to make this bearable, I added a 'have_run'
dictionary to the Distribution class to keep track of which commands
have been run. So now not only are command classes singletons,
but their 'run' method can only be invoked once -- both restrictions
enforced by Distribution.
The code is checked into CVS, or you can download a snapshot at
http://www.python.org/sigs/distutils-sig/distutils-19990607.tar.gz
Hope someone (Amos?) can try the new version under NT. Any takers for
Mac OS?
BTW, all parties involved in the Great "Where Do We Install Stuff?"
Debate should take a good, hard look at the 'set_final_options()' method
of the Install class in distutils/install.py; this is where all the
policy decisions about where to install files are made. Currently it
apes the Python 1.5 situation as closely as I could figure it out.
Obviously, this is subject to change -- I just don't know to *what* it
will change!
Greg
--
Greg Ward - software developer gward(a)cnri.reston.va.us
Corporation for National Research Initiatives
1895 Preston White Drive voice: +1-703-620-8990
Reston, Virginia, USA 20191-5434 fax: +1-703-620-0913
Hi all,
I've been aware that the distutils sig has been simmerring away, but
until recently it has not been directly relevant to what I do.
I like the look of the proposed api, but have one question. Will this
support an installed system that has multiple versions of the same
package installed simultaneously? If not, then this would seem to be a
significant limitation, especially when dependencies between packages
are considered.
Assuming it does, then how will this be achieved? I am presently
managing this with a messy arrangement of symlinks. A package is
installed with its version number in it's name, and a separate
directory is created for an application with links from the
unversioned package name to the versioned one. Then I just set the
pythonpath to this directory.
A sample of what the directory looks like is shown below.
I'm sure there is a better solution that this, and I'm not sure that
this would work under windows anyway (does windows have symlinks?).
So, has this SIG considered such versioning issues yet?
Cheers,
Tim
--------------------------------------------------------------
Tim Docker timd(a)macquarie.com.au
Quantative Applications Division
Macquarie Bank
--------------------------------------------------------------
qad16:qad $ ls -l lib/python/
total 110
drwxr-xr-x 2 mts mts 512 Nov 11 11:23 1.1
-r--r----- 1 root mts 45172 Sep 1 1998 cdrmodule_0_7_1.so
drwxr-xr-x 2 mts mts 512 Sep 1 1998 chart_1_1
drwxr-xr-x 3 mts mts 512 Sep 1 1998 Fnorb_0_7_1
dr-xr-x--- 3 mts mts 512 Nov 11 11:21 Fnorb_0_8
drwxr-xr-x 3 mts mts 1536 Mar 3 12:45 mts_1_1
dr-xr-x--- 7 mts mts 512 Nov 11 11:22 OpenGL_1_5_1
dr-xr-x--- 2 mts mts 1024 Nov 11 11:23 PIL_0_3
drwxr-xr-x 3 mts mts 512 Sep 1 1998 Pmw_0_7
dr-xr-x--- 2 mts mts 512 Nov 11 11:21 v3d_1_1
qad16:qad $ ls -l lib/python/1.1
total 30
lrwxrwxrwx 1 root other 29 Apr 10 10:43 _glumodule.so -> ../OpenGL_1_5_1/_glumodule.so
lrwxrwxrwx 1 root other 30 Apr 10 10:43 _glutmodule.so -> ../OpenGL_1_5_1/_glutmodule.so
lrwxrwxrwx 1 root other 22 Apr 10 10:43 _imaging.so -> ../PIL_0_3/_imaging.so
lrwxrwxrwx 1 root other 36 Apr 10 10:43 _opengl_nummodule.so -> ../OpenGL_1_5_1/_opengl_nummodule.so
lrwxrwxrwx 1 root other 27 Apr 10 10:43 _tkinter.so -> ../OpenGL_1_5_1/_tkinter.so
lrwxrwxrwx 1 mts mts 21 Apr 10 10:43 cdrmodule.so -> ../cdrmodule_0_7_1.so
lrwxrwxrwx 1 mts mts 12 Apr 10 10:43 chart -> ../chart_1_1
lrwxrwxrwx 1 root other 12 Apr 10 10:43 Fnorb -> ../Fnorb_0_8
lrwxrwxrwx 1 mts mts 12 Apr 10 10:43 mts -> ../mts_1_1
lrwxrwxrwx 1 root other 15 Apr 10 10:43 OpenGL -> ../OpenGL_1_5_1
lrwxrwxrwx 1 root other 33 Apr 10 10:43 opengltrmodule.so -> ../OpenGL_1_5_1/opengltrmodule.so
lrwxrwxrwx 1 root other 33 Apr 10 10:43 openglutil_num.so -> ../OpenGL_1_5_1/openglutil_num.so
lrwxrwxrwx 1 root other 10 Apr 10 10:43 PIL -> ../PIL_0_3
lrwxrwxrwx 1 mts mts 10 Apr 10 10:43 Pmw -> ../Pmw_0_7
lrwxrwxrwx 1 root other 10 Apr 10 10:43 v3d -> ../v3d_1_1
Hello Everybody:
I am trying to install distribute-0.6.25 in a windows 7 machine. I have
python 2.7.3 in 32 bits, although the machine is 64 bits. I installed
the 32 bit python version because I want to install ipython and there
is no 64 bit builds of the Windows installer for ipython.
In any case, upon installing disuitils with
python setup.py install
I get the following error
error:
C:\manuel\prog_red\python\distribute-0.6.25\distribute-0.6.25\setuptools\cli-32.exe:
No such file or directory
Any help will be greatly appeciated. Thanks,
Manuel
--
Manuel López Mariscal
Depto. de Oceanografía Física/CICESE
malope(a)cicese.mx
or, removing distutils without replacing it.
** not an actual project **
Proposing mebs, the meta-build system.
What if pip did not depend on setuptools or distutils and the stdlib
did not include distutils or any other build system? Instead, the
installer can only install binary packages, and build systems do not
install but only build binary packages.
A very simple meta-build system "mebs" is used to recognize sdists and
build binary packages. Build systems provide plugins having three
methods,
.recognize()
.metadata()
.build()
An installer downloads an sdist. For each installed build plugin,
.recognize(dir) is called. The first plugin to return True is used.
The plugin's .metadata(dir) is called, returning Metadata 1.3+ format
metadata in a simple email.parser.Parser() multi-dict interface. Used
to fetch any build/install requirements.
.build(dir) is called to create the binary package.
The installer installs the binary package.
The first time you download an sdist, the build system/installer has
to download a pre-built binary package of distutils (because it has
been removed from the standard library). Alternatively a minimal
setup.cfg build_system=x is consulted to download something other than
distutils, the newly installed build plugin recognizes the sdist, and
the package is built and installed.
You wouldn't have to actually remove distutils, but every other build
system could be made to compete with it on equal footing. Binary
packages are used as the lingua franca because, unlike build systems,
binary packages are simple enough that there can be multiple
compatible implementations.
I've been looking at the details of PEP 376 (Database of Installed
Python Distributions) and there are a couple of aspects that I don't
think work properly alongside PEP 370 (Per-user site-packages
directory)..
1. The dist-info directory for a distribution is stated as being
"located in the site-packages directory".
It's not clear how this is intended to work in a PEP 370 world with
multiple site-packages. What I propose is that the description be
changed to be worded in terms of sysconfig-style locations: the
dist-info directory is located in whichever of purelib or platlib is
used by the distribution. When the distribution uses both, purelib is
preferred, when it uses neither (!) purelib is used. In nearly all
cases, this is the same as currently. The exceptions are posix_home
(where the directory name isn't "site-packages" but its function is
the same), posix_prefix (where purelib and platlib differ, and PEP 376
is currently ambiguous as to which is implied), and any custom schemes
that might be created (where PEP 376 is silent, and this proposal has
the benefit of at least being specific). I do not believe this changes
any actual practice - as far as I have been able to determine any code
using dist-info at the moment follows this proposal in the corner
cases where it differs from PEP 376.
2. File paths in RECORD are stated as being relative to the "base
location" as long as the files sit under that location, or under the
"install prefix" where that is above the base location. That's a messy
but precise way of saying you can go up a bit as long as you stay
within sys.prefix. (Other paths are platform format absolute paths,
which is an ugly discrepancy but the only really viable option).
Again, this doesn't work as I'd expect it should in a PEP 370 user
site-packages.
In this case, the answer isn't quite as clear. I would suggest,
looking at the schemes defined in sysconfig, allowing any files
located in one of the defined sysconfig paths (for the current scheme)
to be recorded as relative paths. The paths should be relative to
whichever of purelib and platlib was chosen in (1) above. The
exception is that where pureXXX and platXXX do not use the same base
(posix_prefix and possibly custom schemas) it should not be allowed to
have a relative path from a pureXXX to a platXXX or vice versa. That
equates to something slightly stricter than the current scheme
(although not in a way that's likely to be used in practice), but
using the appropriate one of {base} or {userbase} rather than
sys.prefix. As noted, the two exceptions are custom schemes (where PEP
376 is silent and would probably end up effectively mandating platform
absolute paths throughout) and posix_prefix, where
platlib/platinclude/platstdlib are located under {platbase} rather
than {base} and the current proposal would probably allow relative
paths to be used a little more often that PEP 376 allows. Current
practice that I've seen here is not as clear cut, but mostly in the
sense that code doesn't consider the corner cases at all, and probably
only follows PEP 376 by luck, if at all...
Comments would be appreciated. I'm pretty happy that my proposal for
(1) is an improvement. With (2) I'm concerned about the posix_prefix
case, particularly as I'm a Windows developer and my understanding of
Python's layout on POSIX is limited. But I honestly don't think it's
possible to do much better than my proposal, and I do think that PEP
376 as it stands now is distinctly worse because it doesn't consider
PEP 370 or the posix_prefix case.
Also, while these proposals are not 100% backward compatible, I don't
believe they change behaviour in the most common scenarios, and given
that PEP 376 currently has limited adoption (mainly in distutils2, I
believe) I'd suggest that the minor compatibility break now is better
than keeping the current system until it's more widely adopted and
there are more users to impact. Obviously I'd be looking for views
from Tarek and Éric in particular here, as it's their code in
distutils2 that would be directly impacted.
Paul.
I think Metadata 1.3 is done. Who would like to czar?
On Oct 22, 2012 12:53 PM, "Daniel Holth" <dholth(a)gmail.com> wrote:
> http://hg.python.org/peps/rev/50e8ea1a17a0
>
> Based on the other "required" field's absence in the wild, only
> "Metadata-Version", "Name", "Version", and "Summary" are required.
> Hopefully a clearer explanation of 0, 1, or many occurrences of each
> field.
>
I'd like to submit the Wheel PEPs 425 (filename metadata), 426
(Metadata 1.3), and 427 (wheel itself) for acceptance. The format has
been stable since May and we are preparing a patch to support it in
pip, but we need to earn consensus before including it in the most
widely used installer.
Wheel is a binary packaging format that is mostly based on the
phenomenal work done by 'packaging' as PEP 376 et al. The resulting
packages solve packaging problems by being installable without
setup.py or any variation of distutils, lxml can be installed in 0.7
seconds, and a simple installer is just "unzip" inside site-packages.
Wheel installers know about the major version number of the spec
itself, and will refuse to install version 2.0 wheels if they do not
understand them, so the format can be changed down the line.
Let me know what I need to do to get it accepted, if anything needs to
be added or revised, or, preferably, that it is awesome and you want
to use it ASAP.
Thanks,
Daniel Holth
I can't install Sphinx in a Python 3.2 directory with distribute
0.6.13 installed due to a bug in outdated distribute. Sphinx uses
distribute_setup.py and if no setuptools installed it fetches new
version where there is no such problem. The check is the following
code:
try:
from setuptools import setup, find_packages
except ImportError:
import distribute_setup
distribute_setup.use_setuptools()
from setuptools import setup, find_packages
What is the proper way to modify it to make distribute_setup.py
upgrade distribute if necessary?
--
anatoly t.
I've started a list wheel(a)librelist.com to discuss the implementation
of the 'wheel' binary package format, instead of discussing it all on
this list. Mail the list to join. We are hoping to have support merged
into pip soon.
Daniel H
