Recently, "Pete Shinners" <pete(a)visionart.com> said:
> first, distutils on macos does not know where its own
> "site-packages" directory is. it actually asks the user
> where it is when installing. with all the talk recently
> on getting the install paths straightened out, i hope
> this gets cleaned up on the macos side.
This is the second report I hear of strange things with site-packages
with MacPython, but I have absolutely no idea what the problem
is. MacPython site-packages handling is identical to how unix does
it, and it lives in the exact same place. As I'm not experiencing this
problem I'd like to get into contact with people who have this
problem.
> the problem is that distutils cannot compile and libaries
> that require linking to other libraries. it is very close,
> but there are a couple "one-line" fixes needed to get it
> working.
I know about this problem, but (a) I have very little time and an
enormous todolist, and (b) I don't know of any reasonably simple
distutils-based packages that use the library (or application)
targets.
I posted a fairly detailed description to the pythonmac-sig yesterday
of what would be needed to get mac-distutils to build library and app
targets, if someone else could jump in that would be really nice...
--
Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++
Jack.Jansen(a)oratrix.com | ++++ if you agree copy these lines to your sig ++++
www.oratrix.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm
I'm switching from autoconf to the distutils for building and
installing my Python application. This application includes one
pure-python package, one impure extension package, and various modules
in the root package.
I've figured most of it out except for two things that I used to do
using autoconf:
1) Install two python scripts in a system-wide bin directory (not
site-packages)
2) Create a new .py file by doing textual substitution on a .py.in file
Suppose my program is called blarg. I want users to be able to run
"blarg" from their command prompt. The file blarg is a python script
that imports modules from blarg's library directory, which is usually
something like ${exec_prefix}/lib/blarg-X.Y, where X.Y is the blarg
version number.
The reason I used textual substitution is so that I only have to
change the version string in one place, and the same string is
propagated to everyplace that needs it, including the two main
application scripts that are installed in ${prefix}/bin.
How can I do this using distutils?
--Tessa
From: Thomas Heller [mailto:thomas.heller@ion-tof.com]
> I have a possible solution for this problem.
[Description cut]
Sounds OK to me, but if I knew much about this area I'd have covered it in
the PEP :-)
One question: Should sys.extinstallpath be set for all platforms? Cleanrly,
nothing but Windows will use it at present, but is there a meaningful value
it could have on other platforms? If so, exposing it uniformly seems
sensible.
Paul.
From: Thomas Heller [mailto:thomas.heller@ion-tof.com]
> The sources are in CVS:
> http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/python/distutils/misc/
Unfortunately, I don't have CVS access...
> The bdist_wininst installer simply installs into prefix,
> this is what the registry has under
> HKEY_LOCAL_MACHINE\Software\Python\PythonCore\2.1\InstallPath.
>
> Now what should it do?
What does that key *mean*? If it is the directory into which packages should
get installed, then bdist_wininst should keep doing what it does now, and
the Python installer should be changed to put site-packages into that key.
If, on the other hand, this key has a meaning elsewhere in Python, and
changing it would cause a problem, then I would say that this is a bug in
the Windows Installer, which should use a key of its own. In that case, my
recommendation would be to have the Python 2.2 installer create a new key,
and wininst use that if it exists, otherwise fall back to the current key.
That would provide the correct behaviour in the new release, but retain
backward compatibility with earlier versions of Python.
> There are probably some issues here.
Agreed. I apologise if I didn't publicise the PEP in the right places for
these to get picked up earlier - I thought I had. I believe my suggestion
above will do the right thing, but I am not an expert in the intricacies of
Python's use of the registry, so I'd like someone more knowledgeable to
comment, if possible.
Paul.
From: Pete Shinners [mailto:pete@shinners.org]
> for the love of all things good, can we please make a recommendation
> in our PEP that the windows installation location be something other
> than "C:\PYTHON21"? something like "C:\PYTHON21\SITE-PACKAGES" would
> be a big improvement. i thought i heard that macpython recently made
> this "fix", why is the windows version lagging on this?
PEP 250 covers this. I have sent in the final PEP for approval, plus a
patch, but the process appears to be stalled. I guess I need to nag again.
The PEP process doesn't seem to cover non-core Python developers well (eg,
people like me who don't have a way of integrating with the Sourceforge
mechanisms...)
Paul.
From: M.-A. Lemburg [mailto:mal@lemburg.com]
> They should be in the CVS tree of Python on SourceForge.
I don't have CVS access, so I can't get at these, unfortunately...
> About the change: I think distutils should lookup the path in Python's
> site.py file - that way you assure that distutils will work on all
> Python installations rather than only on those which have the site.py
> patch. Otherwise, Python won't find the packages installed in
> Lib/site-packages.
I'm not sure what you intend, here. site.py doesn't export this directory -
it is just one of the directories which gets added to sys.path in site.py.
On Unix, there are more than one such directory (both version-specific and
version-independent), so there isn't, in general, just one such directory. I
don't know how you could encapsulate this in a way which would not clash
with other platforms' policies.
The intention of this change was to be the smallest possible change which
would work. I believe it (or at least, the patch I sent when I submitted the
final version of the PEP) does that for everything except the Windows
Installer. I'll have to defer judgement on how best to address that area to
others better qualified to comment, but see my message to Thomas for my
suggestion.
Hope this helps,
Paul.
From: M.-A. Lemburg [mailto:mal@lemburg.com]
> I don't have a site-packages dir in my installations. Could it be that
> you installed some distutils package which automagically created one
> or that this change in Python 2.1.1 ?
I don't believe so. I have ActiveState Python - it's possible (although
unlikely, I would think) that that version creates site-packages specially.
It's vaguely possible (although unlikely) that I created the directory
manually - it was missing in one of the 2.1 betas, IIRC, but I thought it
reappeared in 2.1 final. In any case, the necessary changes to make sure
that directory exists should be in the Windows Installer package(s) for
Python. I guess that means somewhere in the Wise installer scripts - which I
don't have access to, nor would I know how to change.
It should just be a case of reinstating the behaviour in 2.0, if the
directory really has been lost in 2.1.
> This doesn't seem to do the trick: the Windows installer still installs
> the packages directly to \Python21.
This change should (as I said, it's untested) have ensured that "python
setup.py install" puts the module into site-packages. I don't know what the
installer code in bdist_wininst.py does, as it's a base64-encoded EXE, and I
don't have the sources - surely it uses the distutils sysconfig stuff to get
the value (it has no other way of knowing...)?
Paul.
From: M.-A. Lemburg [mailto:mal@lemburg.com]
Tim Peters wrote:
> Umm, what am I missing? The change to site.py was so simple you could
have
> committed it yourself quicker than it took to write the above. I
committed
> it a few minutes ago. If something else is needed, someone else will have
> to do it (or explain it to me in detail so precise they could do it
themself
> 10x quicker <wink>).
> Cool, but what about the changes needed in distutils to actually
> utilize the new directory and the changes to the Windows installer
> to create the directory at installation time ?
The patch I sent along with the final version of the PEP included the
distutils change (it's only one line, but it's on the PC at home, so I can't
quote it here). I assume that the Python install should ensure that the
site-packages exists (it does at the moment) so I don't see a need for the
wininst installer to check.
Paul.
PS [After a quick rummage...] I *think* the following patch is what is
needed for distutils: I haven't tested it, though, so it would be better to
check the original version (which I did test...)
--- sysconfig.py.orig Thu Apr 19 10:24:24 2001
+++ sysconfig.py Thu Jul 12 09:32:34 2001
@@ -87,7 +87,7 @@
elif os.name == "nt":
if standard_lib:
- return os.path.join(PREFIX, "Lib")
+ return os.path.join(PREFIX, "Lib", "site-packages")
else:
return prefix
At 02:33 PM 7/9/2001 -0400, Mark W. Alexander wrote:
>On Sun, 8 Jul 2001, Andrew Kuchling wrote:
>
>> It seems time to bite the bullet and actually begin designing and
>> implementing a database of installed packages. As a strawman to get a
>> focused discussion started, here's a draft of a PEP, with lots of
>> XXX's in it. Followups to the Distutils SIG, please.
>
>I'm confused. Why? What does this give us that native package managers
>don't. How is it going to keep synchronized with package manager?
One problem is that native package managers don't make sense for
everything. I can't imagine wanting to even deal with many of
the package managers out there for a smaller Python package. I'm
not even convinced that one of the major entrants out there - the
Windows one - does a reasonable job with dependencies, but I'm
pretty ignorant there. And even small packages - a few Python source
files - might want to check for prereqs.