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
Hey there,
I’m using python 2.7/setuptools 3.6 to build an egg of my code (checked into perforce) using my setup.py. This egg gets installed into a virtualenv.
On osx/darwin this works fine.
On windows, the bdist creates scripts and data whose permissions are read-only (attrib+r), and they cannot overwrite themselves in a subsequent build of that egg. Similarly, re-installing a new egg using virtualenv fails because the installed egg’s scripts and data are not writable.
I thought it might be that when checked out from perforce, the permissions stayed read-only during the build of the egg, so I set all the files in my module to be read-write before building. Even when the original source files’ permissions are all set to read-write, the generated bdist egg script/data content end up becoming read-only.
Couple of questions.
1. Since it works fine on osx, it seems like a bug in the windows implementation of setuptools. Is this known behavior, is there a reason for setting this on scripts/data on windows?
2. Is there a hook in the bdist egg build process I can use to set the attributes of the files correctly when the bdist egg is made? How/where should I define this in my setup.py?
Kind regards,
-e
Hey all (but especially the zc.buildout users),
With zc.buildout being used to define repeatable application
deployments, and Docker images acting as a way to snapshot entire
execution environments for ease of deployment on any environment than
can run a container (which is basically any modern Linux at this
point, or will be once CentOS 7 is available), has any experimented
with using zc.buildout from a Dockerfile to define an image?
If yes, is it written up anywhere?
If not, is anyone intrigued enough by the idea to considering trying
it out and writing up the results as a blog post somewhere?
Cheers,
Nick.
--
Nick Coghlan | ncoghlan(a)gmail.com | Brisbane, Australia
hi am blind and am python programmer but i can't write the codes from
python idl should i use notepat ++ and some plugins to write and run
the codes cause the python idlis not accessible with blind and with
the screen reader i hope to hear from you as soon as thanks regards
Hi folks. I'm new to the list and don't mean to impose, but I've been
following some of the recent developments of the PyPA and I'm wondering if
the unreasonable expectations I have for Python packaging are about to come
true, or if there's a simple workaround to achieve some of these goals in
the meantime.
In building the Python 3 application I'm currently working on I have the
end goal of supporting Windows users, Debian-based system users, and maybe
Fedora users with installable distributions they can install without
worrying about dependencies. I won't consider my packaging efforts to be
successful if somebody using one of these systems has to manually install
Python 3.4 or PyQt5 before they can install my application. Ultimately I'd
also like to package my application as a standalone OS X app, but I don't
have access to an OS X system right now.
After some wrestling with cx_Freeze in Python 3.4 on Windows 7 in a
VirtualBox machine, I've been able to put together a satisfactory Windows
test distribution bundled with all its dependencies. setuptools will
produce an rpm package, but I wouldn't know how to make sure the package
depends on PyQt 5 and the QScintilla plugin for PyQt 5, so Fedora users can
install my application without having to know they need these dependencies.
I can't list PyQt5 or PyQt5.Qsci in the "install-requires" setuptools
option because, as far as I understand, this option is only for listing
packages that can be installed by pip. I have managed to set up a Debian
packaging infrastructure such that I can build a Debian binary package with
the command "dh --with python3 binary-indep", but I haven't figured out how
to include an XDG menu entry in the package, and I consider this a
deal-breaker. Of course, setuptools doesn't currently handle XDG menus at
all.
So my wish list for setuptools or a similar tool is:
*
Automated XDG menu entry generation
*
Some way to handle dependencies that can't be installed by pip
*
Automated generation of Debian binary packages good enough to be accepted
into the repositories
*
Automated generation of rpm packages with all the right dependencies (For
all I know this could exist already, but considering the way dependencies
are currently handled by setuptools I really doubt it)
*
In a perfect universe, easy cross-building functionality, so I could
produce a standalone Windows executable or an OS X app from the comfort of
Xubuntu.
Due to the regression reported in [Setuptools #218]( https://bitbucket.org/pypa/setuptools/issue/218/setuppy-develop-fails-with-…), I've removed all versions of Setuptools 4.x and closed that branch.
I will continue to explore the underlying issue, [Setuptools #210]( https://bitbucket.org/pypa/setuptools/issue/210) to seek a proper solution, possibly without backward incompatibility.
Please use Setuptools 3.8.1 or later. If another backward-incompatible release is made for anything other than issue 210, it will tagged as Setuptools 5.0, bypassing 4.0 altogether.
Regards,
Jason
Folks,
I'm trying to help figure out how to do binary wheels for a package that
relies on ctypes and a bundles shared lib (dll, .so. etc)
The trick here is that the python code is quite version and platform
independent: py2 and py3, version 2.7 and 3.3+ (I think)
(it's py_enchant, if anyone is interested:
http://pythonhosted.org/pyenchant/)
So the trick is that the binary wheel will be platform dependent, but not
the code itself, so ideally we'd have one wheel, that for instance (and teh
case at hand) should work on any OS-X box version 10.6 and above, with a
any of python2.7, 3.3, 3.4 (an up?)
Usually, a binary wheel involves compiled extensions, and thus is tied to
a particular python version -- so this is an odd case.
We tried:
pyenchant-1.6.6-py2.py3-none-macosx_10_6_intel.whl
which seems to be saying: any version of python2 or python 3, but only on
macosx 10.6
but trying to install that on my machine (py2.7, os-x 10.6) gives:
pyenchant-1.6.6-py2.py3-none-macosx_10_6_intel.whl is not a supported wheel
on this platform.
(side note: it would be really great if that could be a more useful message
-- what part of the file name didn't match? I know that's a trick, as there
is a whole pile of heuristics to go through, but maybe a way to dump that
process would be helpful...)
Now, this may, in fat be tied to CPython (I have no idea if ctypes
is available on pypy or jython or IronPython...). So I tried:
pyenchant-1.6.6-cp27-none-macosx_10_6_intel.whl
that does, indeed, install on my system.
Also:
pyenchant-1.6.6-cp27.cp33-none-macosx_10_6_intel.whl
works.
As 2.7 is really the only py2 that much matters, no biggie, but is there a
way to get 3.3 and 3.4 and ??? all at once (I don't have py3 on that
machine, so didn't test that...)
So: how should this be done? Is the above the best option there is?
Thanks,
-Chris
--
Christopher Barker, Ph.D.
Oceanographer
Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
Chris.Barker(a)noaa.gov