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.
If you move the files, other things can potentially break, too. For example, any scripts installed will have their shebangs adjusted to point to a particular interpreter, e.g. a venv's interpreter. If they get moved to a different location, the shebang lines may become invalid.
I don't believe that we have to support such moving of files outside of the knowledge of packaging tools.
Regards,
Vinay Sajip
>________________________________
> From: Kevin Horn <kevin.horn(a)gmail.com>
>To: Vinay Sajip <vinay_sajip(a)yahoo.co.uk>
>Sent: Monday, 31 December 2012, 19:19
>Subject: Re: [Distutils] Some clarifications and/or corrections to PEP 376
>
>
>On Mon, Dec 31, 2012 at 12:59 PM, Vinay Sajip <vinay_sajip(a)yahoo.co.uk> wrote:
>
>
>>
I agree that PEP 376 isn't ideal in what it specifies in this area. The simplest
>>solution would surely be absolute paths only. What are the downsides apart from
>>the disk space used for the extra lengths of the filenames?
>>
>>Regards,
>>
>>Vinay Sajip
>>
>>
>>
>
>
>If you ever move the files, the absolute paths won't be valid any more. It seems kind of unlikely that this would cause problems, but it might.
>
>--
>Kevin Horn
>
>
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.
Hi everybody,
I am compiling an extension consisting of a number of files; some of
them are c++11, some are plain C. The compiler (gcc) detects language by
extension, not whether the g++/gcc binary is called. I am passing
"-std=c++11" to the compiler because of c++ files. *.c files are
correctly treated as plain C by the compiler and it says:
cc1.exe: warning: command-line option '-std=c++11' is valid for
C++/ObjC++ but not for C [enabled by default]
I don't mind seeing that warning, but I would be concerned should it
become an error at some point in the future.
As far as I see, the current design supposes the whole extension is a
single language, and single set of compiler flags. Is there a way around it?
Cheers, Vaclav
Dear Nipype experts,
i was trying to install nipype software by easy_install command and had the
following error:
install_dir /usr/loca/lib/python2.6/dist-packages/
error: can't creat or remove files in install directory
Something like "permission denied", so can you advice me on this?
Thank you in advance!
Hello,
I would like to declare empty namespace package "A.B" inside the
setup.py of "A", but I am getting
error in A setup command: Distribution contains no modules or
package for namespace package "A.B".
The reason for declaring empty namespace package is that I could always
do "import A.B" from A, knowing that the import will never fail. The
current situation is that depending on whether some A.B.* is installed,
import A.B succeeds or fails with ImportError, so I have a few places with
try: import A.B
except ImportError: pass # no A.B.* installed
I can live with that, though if there is some option to allow empty
namespace package, I would be glad to hear about it.
I am using setuptools 0.6.28.
Cheers, Vaclav
