From tlau@ofb.net  Fri Jul  6 21:42:01 2001
From: tlau@ofb.net (Tessa Lau)
Date: Fri Jul  6 20:42:01 2001
Subject: [Distutils] Distributing python applications
Message-ID: <1619.994466512@apathy.cs.washington.edu>

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 akuchlin@mems-exchange.org  Mon Jul  9 00:48:01 2001
From: akuchlin@mems-exchange.org (Andrew Kuchling)
Date: Sun Jul  8 23:48:01 2001
Subject: [Distutils] Package DB: strawman PEP
Message-ID: <20010708234624.A30892@ute.cnri.reston.va.us>

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.

--amk

PEP: XXX
Title: A Database of Installed Python Packages
Version: $Revision: 1.1 $
Author: A.M. Kuchling <akuchlin@mems-exchange.org>
Type: Standards Track
Created: 08-Jul-2001
Status: Draft
Post-History: 

Introduction

    This PEP describes a format for a database of Python packages 
    installed on a system.


Requirements

    We need a way to figure out what packages, and what versions of
    those packages, are installed on a system.  We want to provide
    features similar to CPAN, APT, or RPM.  Required use cases that
    should be supported are:
 
        * Is package X on a system?  
        * What version of package X is installed?
        * Where can the new version of package X be found?  
          XXX Does this mean "a home page where the user can go and
          find a download link", or "a place where a program can find
          the newest version?"  Perhaps both...
        * What files did package X put on my system?
        * What package did the file x/y/z.py come from?
        * Has anyone modified x/y/z.py locally?


Database Location

    The database lives in a bunch of files under
    <prefix>/lib/python<version>/install/.  This location will be
    called INSTALLDB through the remainder of this PEP.

    XXX is that a good location?  What effect does platform-dependent code
    vs. platform-independent code have on this?

    The structure of the database is deliberately kept simple; each
    file in this directory or its subdirectories (if any) describes a
    single package.

    The rationale for scanning subdirectories is that we can move to a
    directory-based indexing scheme if the package directory contains
    too many entries.  That is, instead of $INSTALLDB/Numeric, we
    could switch to $INSTALLDB/N/Nu/Numeric or some similar scheme.

    XXX how much do we care about performance?  Do we really need to
    use an anydbm file or something similar?

    XXX is the actual filename important?  Let's say the installation
    data for PIL is in the file INSTALLDB/Numeric.  Is this OK?  When
    we want to figure out if Numeric is installed, do we want to open
    a single file, or have to scan them all?  Note that for
    human-interface purposes, we'll often have to scan all the
    packages anyway, for a case-insensitive or keyword search.


Database Contents

    Each file in $INSTALLDB or its subdirectories describes a single
    package, and has the following contents:

        An initial line listing the sections in this file, separated
        by whitespace.  Currently this will always be 'PKG-INFO
        FILES'.  This is for future-proofing; if we add a new section,
        for example to list documentation files, then we'd add a DOCS
        section and list it in the contents.  Sections are always
        separated by blank lines.  XXX too simple?

        [PKG-INFO section] An initial set of RFC-822 headers
        containing the package information for a file, as described in
        PEP 241, "Metadata for Python Software Packages".

        A blank line indicating the end of the PKG-INFO section.

        An entry for each file installed by the package.  
        XXX Are .pyc and .pyo files in this list?  What about compiled
        .so files?  AMK thinks "no" and "yes", respectively.

    Each file's entry is a single tab-delimited line that contains the
    following fields: 
    XXX should each file entry be all on one line and
    tab-delimited?  More RFC-822 headers?  AMK thinks tab-delimited
    seems sufficent.

        * The file's size
 
        * XXX do we need to store permissions?  The owner/group?  

        * An MD5 digest of the file, written in hex.  (XXX All 16
          bytes of the digest seems unnecessary; first 8 bytes only,
          maybe?  Is a zlib.crc32() hash sufficient?)

        * The file's full path, as installed on the system.  (XXX
          should it be relative to sys.prefix, or sys.prefix +
          '/lib/python<version>?'  If so, full paths are still needed;
          consider a package that installs a startup script such as
          /etc/init.d/zope)
          
        * XXX some sort of type indicator, to indicate whether this is
          a Python module, binary module, documentation file, config
          file?  Do we need this?

    A package that uses the Distutils for installation will
    automatically update the database.  Packages that roll their own
    installation 

    XXX what's the relationship between this database and the RPM or
    DPKG database?  I'm tempted to make the Python database completely
    optional; a distributor can preserve the interface of the package
    management tool and replace it with their own wrapper on top of
    their own package manager.  (XXX but how would the Distutils know
    that, and not bother to update the Python database?)

    
Deliverables
  
    Patches to the Distutils that 1) implement a InstallationDatabase
    class, 2) Update the database when a new package is installed.  3)
    a simple package management tool, features to be added to this
    PEP.  (Or a separate PEP?)  


References

    [1] Michael Muller's patch (posted to the Distutils-SIG around 28
        Dec 1999) generates a list of installed files.


Acknowledgements

    Ideas for this PEP originally came from postings by Greg Ward,
    Fred Drake, Mats Wichmann, and others.


Copyright

    This document has been placed in the public domain.


Local Variables:
mode: indented-text
indent-tabs-mode: nil
End:





From dan@cgsoftware.com  Mon Jul  9 04:18:01 2001
From: dan@cgsoftware.com (Daniel Berlin)
Date: Mon Jul  9 03:18:01 2001
Subject: [Distutils] Re: Package DB: strawman PEP
In-Reply-To: <20010708234624.A30892@ute.cnri.reston.va.us> (Andrew Kuchling's message of "Sun, 8 Jul 2001 23:46:24 -0400")
References: <20010708234624.A30892@ute.cnri.reston.va.us>
Message-ID: <87bsmur2pc.fsf@cgsoftware.com>

Andrew Kuchling <akuchlin@mems-exchange.org> writes:

>     XXX how much do we care about performance?  Do we really need to
>     use an anydbm file or something similar?
> 
>     XXX is the actual filename important?  Let's say the installation
>     data for PIL is in the file INSTALLDB/Numeric.  Is this OK?  When
>     we want to figure out if Numeric is installed, do we want to open
>     a single file, or have to scan them all?  Note that for
>     human-interface purposes, we'll often have to scan all the
>     packages anyway, for a case-insensitive or keyword search.

Errr, how so?
If you mean keyword/case-insensitive on package description/name,
just keep an anydbm whose sole purpose is to list the installed
packages and descriptions, and nothing else.
Then you could just search all they keys, rather than have to open and
close 600 files or whatever. Every time (if you cached it in memory, instead of
doing it every time,  you'd have an in memory version of this anydbm
database, and if you go that far, you might as well just store it in the database).

This can easily be rebuilt in case of corruption, since *it* was
generated initially by scanning the files (you just keep it up to date
when you install packages, and if something gets out of whack,
completely rebuild it).

> 
> Database Contents
> 
>     Each file in $INSTALLDB or its subdirectories describes a single
>     package, and has the following contents:
> 
>         An initial line listing the sections in this file, separated
>         by whitespace.  Currently this will always be 'PKG-INFO
>         FILES'.  This is for future-proofing; if we add a new section,
>         for example to list documentation files, then we'd add a DOCS
>         section and list it in the contents.  Sections are always
>         separated by blank lines.  XXX too simple?

Can we try to keep delimiters the same where possible (IE why use
whitespace here, but tabs for file entries)?  



> 
>         [PKG-INFO section] An initial set of RFC-822 headers
>         containing the package information for a file, as described in
>         PEP 241, "Metadata for Python Software Packages".
> 
>         A blank line indicating the end of the PKG-INFO section.
> 
>         An entry for each file installed by the package.  
>         XXX Are .pyc and .pyo files in this list?  What about compiled
>         .so files?  AMK thinks "no" and "yes", respectively.
> 
>     Each file's entry is a single tab-delimited line that contains the
>     following fields: 
>     XXX should each file entry be all on one line and
>     tab-delimited?  More RFC-822 headers?  AMK thinks tab-delimited
>     seems sufficent.
> 
>         * The file's size
>  
>         * XXX do we need to store permissions?  The owner/group?  
> 
owner/group will get you in trouble if the owner/group doesn't exist
on the other system.
>         * An MD5 digest of the file, written in hex.  (XXX All 16
>           bytes of the digest seems unnecessary; first 8 bytes only,
>           maybe?  Is a zlib.crc32() hash sufficient?)
We should use either MD5 or sha1.
MD5 can be done at 10 meg a second (easily) on a pentium 90. So it's
fast enough.  8 bytes is fine enough, just make it the first 8.
crc32 will probably not be faster (unless you have *huge* .py files,
you are going to be dominated here by open/close/seek time, not
read/checksum calculation time)
> 
>         * The file's full path, as installed on the system.  (XXX
>           should it be relative to sys.prefix, or sys.prefix +
>           '/lib/python<version>?'  If so, full paths are still needed;
>           consider a package that installs a startup script such as
>           /etc/init.d/zope)
>           
>         * XXX some sort of type indicator, to indicate whether this is
>           a Python module, binary module, documentation file, config
>           file?  Do we need this?
Well, it would allow you to purge docs seperately from the rest of the
package, or purge everything but the config files. I've used both
options myself. The other option is to put docs in a seperate package.

> 
>     A package that uses the Distutils for installation will
>     automatically update the database.  Packages that roll their own
>     installation 
> 
>     XXX what's the relationship between this database and the RPM or
>     DPKG database?  I'm tempted to make the Python database completely
>     optional; a distributor can preserve the interface of the package
>     management tool and replace it with their own wrapper on top of
>     their own package manager.  (XXX but how would the Distutils know
>     that, and not bother to update the Python database?)

Well, why don't we email the package owners for a few distributions,
and see what they think?
:)


-- 
"My dental hygienist is cute.  Every time I visit, I eat a whole
package of Oreo cookies while waiting in the lobby.  Sometimes
she has to cancel the rest of the afternoon's appointments.
"-Steven Wright


From pete@shinners.org  Mon Jul  9 13:29:13 2001
From: pete@shinners.org (Pete Shinners)
Date: Mon Jul  9 12:29:13 2001
Subject: [Distutils] Package DB: strawman PEP
References: <20010708234624.A30892@ute.cnri.reston.va.us>
Message-ID: <002901c10894$60851140$1900a8c0@petebox>

> 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.

it's definitely off to a decent start, i'll throw out some
"things to consider"...


if a user changes the install prefix and installs the package
somewhere "off the path", does the package manager keep track
of it? i'm guessing it should only handle packages inside the
python treee?

it will be hard to add an automatic "download link" for updating
packages. what if a package has increased multiple versions
since the package was installed? i think this falls into the
realm of the nebulous online package library. the good news
about going with a central online repository is that you can
automatically get new packages, not just update ones you
already have.

how to handle the python standard library? is there just a
single entry for the entire library? does it not matter since
the user can just query the python version and get a good idea
of what is available? i'm kind of thinking of the "optional"
standard runtime libraries. then again, it's easy enough to see
if they exist by catching any Import exceptions, and i don't
think this sort of thing has been a problem to anyone in the
past. no need to kill ourselves handling something that hasn't
bothered anyone before. :]

i do like the database of installed files. i see it can
already be created by distutils with some options, it should
mean 'uninstall' tools are pretty much automatic.

we'll need some information in the distutils setup.py to
define what the dependencies for a package really are. how
should this be layed out? package names with a minimum version?

what about binary packages. most windows users don't have a
compilers, and will need prebuilt extension modules for their
system. again, i believe this falls more into the roll of having
an online package repository, but it would be worth mentioning
in this pep?

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?


as for some of the questions you posed...

i was thinking the name would be important. for each installed
package you have a single file with the name of the package (and
some appropriate extension maybe). the file would just contain
the PKG-INFO with the list of installed files at the end?
(is that enough information?). then it becomes simple to see if
and what version of a package is installed. perhaps the name
should be case-INsensitive. so there is no confusion between
"Numeric" and "numeric".

things that would take longer with that setup is to find which
package a file belongs to, which packages are dependent on a given
package, and that sort of stuff.

obviously there will need to be some sort of "packages" module
in standard python that has functions to perform all these tasks.
it should also include a commandline interface so it can be 
simply accessed by users...

(forgive the name, if that sort of thing has been done to death)
pyckage.py list             #list installed packages
pyckage.py update pygame    #get latest version of pygame
pyckage.py update *         #get latest version of all packages
pyckage.py showdeps Numeric #you get the idea?

anyways, perhaps the PEP should list what functions are available
and how they would be accessed on the commandline (or is that too
much detail for a PEP?)


oh, one last thing to consider...
at this point, my package has been put into several different
binary packages, RPM and DEB for example. we need to figure
something out here. perhaps an installed package can be marked
"Not Under Python Package Control", so it can't be removed
or updated from the python package stuff.
perhaps we could be more flexible and allow the package to
embed commands to do these things for it? "uninstall_command"
could be set to something like "apt-get remove pygame"?

on the other hand, if a really nice package management system
is in place, we may no longer need to rely on OS tools to do
the packaging for us?

hmm, same with windows too. if a user installs a package with
the a distutils executable bdist, it adds some entries to the
registry to allow the user to uninstall it. if this python
package management uninstalls the package, should there be
some sort of hook so it can clean out the registry keys too?


whew, a lot of things here. perhaps they don't all need to be
addressed by the PEP for now, but as long as they are tickling
in the back of someone's head as this gets developed i think
we'll be in a much better position :]





From slash@dotnetslash.net  Mon Jul  9 15:32:01 2001
From: slash@dotnetslash.net (Mark W. Alexander)
Date: Mon Jul  9 14:32:01 2001
Subject: [Distutils] Package DB: strawman PEP
In-Reply-To: <20010708234624.A30892@ute.cnri.reston.va.us>
Message-ID: <Pine.LNX.4.21.0107091411520.1770-100000@llave.eproinet.com>

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?

If I understand correctly, most of what's desired here could be
accomplished by including the PEP 241 metadata in the module in a
manner that could be inspected upon import. Distutils could even go so
far as to create a PKG_INFO subpackage ao you could import
mymodule.PKG_INFO. If is succeeds, it's a distutils created module and
contains all PEP241 required information.

>     XXX what's the relationship between this database and the RPM or
>     DPKG database?  I'm tempted to make the Python database completely
>     optional; a distributor can preserve the interface of the package
>     management tool and replace it with their own wrapper on top of
>     their own package manager.  (XXX but how would the Distutils know
>     that, and not bother to update the Python database?)

If it's optional, then maybe, sometimes, you might have the
information that it could have provided you. In the long run, your
better off making it simple and painless to create packages for the
native system's package manager. Then people need look only one place
for everything. (I still like the idea of the 241 metadata being
accessible in the module itself. It makes it more convenient for
module authors to query information specific to distutils module
relationships.)

Mark



From danm@ActiveState.com  Mon Jul  9 18:10:02 2001
From: danm@ActiveState.com (Dan Milgram)
Date: Mon Jul  9 17:10:02 2001
Subject: PyPPM/[Distutils] Package DB: strawman PEP
In-Reply-To: <20010708234624.A30892@ute.cnri.reston.va.us>
Message-ID: <Pine.LNX.4.30.0107091304140.15223-100000@latte.ActiveState.com>

I'd like to take the opportunity to discuss some of the work done at
ActiveState that is pertinent to the discussion at hand. While I suspect
most people subscribed to this list are already familiar, I'll assume
nothing for clarity sake.

In its current form a repository is accessible which allows for easy
installation of python packages
(see http://www.ActiveState.com/PPMPackages/PyPPM/2.1/ )

Our equivalent of PKG-INFO is a PPD file
type that stores data in an XML format. A PPD file describes a PyPPM
package which is a built distutils package in an archive format (.tar.gz
or .zip depending on platform). While currently packages can only be
downloaded, a demo will be presented at the upcoming O'Reilly open source
conference of a repository which exposes functionality discussed in the
catalog SIG.

In addition to the standard metadata  handled by distutils
(author,author_email,license, etc.) a PPD can contain
the following elements:

INSTALL - an installation string for installing packages distributed in a
non-distutils binary distribution format (eg. RPM, setup.exe etc.)

DEPENDENCIES - handles dependencies (eg. PIL-Graph's dependence on PIL)

IMPLEMENTATION - an implementation may contain a PYTHONCORE,
ARCHITECTURE, and OS elements, in addition to a CODEBASE element. The
CODEBASE element defines the URL of the actual package, while the others
define the relevant implementation characteristics of said package

When a PyPPM package is installed on a client machine package instance
data is stored in an XML database. In its current form, the database
stores configuration information for the PyPPM client (eg. a repository
location is specified), and descriptions of packages installed
(essentially all the information contained in a PPD minus implementation
data for other platforms).

Additionally storing each file installed within a package would allow for
provision of the functionality suggested (and sorely needed :)) in
Andrew's PEP. I would argue that adopting an XML format would be
beneficial, unless performance is deemed a major issue, however I suspect
people don't want to rehash PPD vs. PKG-INFO type arguments

>From a compatibility standpoint it would be nice if the database info is
not an addon to distutils through another package manager, but intrinsic
to it.

Finally some random thoughts:
- It would be great if we could get some momentum behind PEP 250 - this
will simplify the task of adopting the Package DB PEP

- it would be nice if we could remove potential metadata conflict issues
that could exist, as identical metadata fields can be stored within the
setup.py and the PKG_INFO file (what's deemed canonical by the database?)

- the core python version should be stored for a given package in the
database, so that a package manager can "do the right thing" when a python
distribution is upgraded. Arguably, functionality for maintaining database
consistency between unpure python packages and a given python distribution
could be the domain of the database functionality

Regards,
Dan

-- 
Dan Milgram/ActiveState Developer
New! ASPN - ActiveState Programmer Network
Essential programming tools and information
http://www.ActiveState.com/ASPN



From Paul.Moore@atosorigin.com  Wed Jul 11 05:34:03 2001
From: Paul.Moore@atosorigin.com (Moore, Paul)
Date: Wed Jul 11 04:34:03 2001
Subject: PEP 250 - site-packages on Windows: (Was: [Distutils] Package DB:
 strawman PEP)
Message-ID: <714DFA46B9BBD0119CD000805FC1F53B01B5AEDF@ukrux002.rundc.uk.origin-it.com>

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 bsass@freenet.edmonton.ab.ca  Wed Jul 11 07:26:01 2001
From: bsass@freenet.edmonton.ab.ca (Bruce Sass)
Date: Wed Jul 11 06:26:01 2001
Subject: [Distutils] Re: Package DB: strawman PEP
In-Reply-To: <20010708234624.A30892@ute.cnri.reston.va.us>
Message-ID: <Pine.LNX.4.33.0107100058160.13382-100000@bms>

> PEP: XXX
> Title: A Database of Installed Python Packages
> Version: $Revision: 1.1 $
> Author: A.M. Kuchling <akuchlin@mems-exchange.org>
> Type: Standards Track
> Created: 08-Jul-2001
> Status: Draft
> Post-History:
>
> Introduction
>
>     This PEP describes a format for a database of Python packages
>     installed on a system.
>
>
> Requirements
>
>     We need a way to figure out what packages, and what versions of
>     those packages, are installed on a system.  We want to provide
>     features similar to CPAN, APT, or RPM.  Required use cases that
>     should be supported are:
>
>         * Is package X on a system?
>         * What version of package X is installed?
>         * Where can the new version of package X be found?
>           XXX Does this mean "a home page where the user can go and
>           find a download link", or "a place where a program can find
>           the newest version?"  Perhaps both...

Both, but I would expect that presenting the user with a URL would be
a rare case (perhaps a commandline option).

>         * What files did package X put on my system?
>         * What package did the file x/y/z.py come from?
>         * Has anyone modified x/y/z.py locally?

* dependencies !


> Database Location
>
>     The database lives in a bunch of files under

s/bunch of files/file/

filesystem access is just too slow, IMHO

>     <prefix>/lib/python<version>/install/.  This location will be
>     called INSTALLDB through the remainder of this PEP.
>
>     XXX is that a good location?  What effect does platform-dependent code
>     vs. platform-independent code have on this?

I don't think it is necessary to tie the DB to a specific version of
Python, or have multiple DBs if multiple versions of Python are
installed.

You can get what (I think) you are after by considering that each
package will either depend on "python" or "python-<version>"; when it
comes to installing or removing a package you either do the operation
over all installed Pythons, or just the version the package depends
on.

>     The structure of the database is deliberately kept simple; each
>     file in this directory or its subdirectories (if any) describes a
>     single package.
>
>     The rationale for scanning subdirectories is that we can move to a
>     directory-based indexing scheme if the package directory contains
>     too many entries.  That is, instead of $INSTALLDB/Numeric, we
>     could switch to $INSTALLDB/N/Nu/Numeric or some similar scheme.
>
>     XXX how much do we care about performance?  Do we really need to
>     use an anydbm file or something similar?

enough not to use a file system based INSTALLDB  :)

The DB should be human readable, and easy to modify without needing
special tools (saved my butt a few times with Debian's system).

You really need two databases...
one for what is available,
one for what is installed.

If you don't do a local available DB, the system is useless without a
'net connection; if you keep an available list and flag what is
installed, you have piles of data to read through everytime you want
to inspect or display what installed is on the system.

>     XXX is the actual filename important?  Let's say the installation
>     data for PIL is in the file INSTALLDB/Numeric.  Is this OK?  When
>     we want to figure out if Numeric is installed, do we want to open
>     a single file, or have to scan them all?  Note that for
>     human-interface purposes, we'll often have to scan all the
>     packages anyway, for a case-insensitive or keyword search.

...best done (speed and efficiency wise) with a file based, rather
than filesystem based, database(s), right?


> Database Contents
>
>     Each file in $INSTALLDB or its subdirectories describes a single
>     package, and has the following contents:
>
>         An initial line listing the sections in this file, separated
>         by whitespace.  Currently this will always be 'PKG-INFO
>         FILES'.  This is for future-proofing; if we add a new section,
>         for example to list documentation files, then we'd add a DOCS
>         section and list it in the contents.  Sections are always
>         separated by blank lines.  XXX too simple?

Too complicated.

>         [PKG-INFO section] An initial set of RFC-822 headers
>         containing the package information for a file, as described in
>         PEP 241, "Metadata for Python Software Packages".
>
>         A blank line indicating the end of the PKG-INFO section.
>
>         An entry for each file installed by the package.
>         XXX Are .pyc and .pyo files in this list?  What about compiled
>         .so files?  AMK thinks "no" and "yes", respectively.

Ya.  You need a list of what is in the package, the list of generated
files can always be generated again.

>     Each file's entry is a single tab-delimited line that contains the
>     following fields:
>     XXX should each file entry be all on one line and
>     tab-delimited?  More RFC-822 headers?  AMK thinks tab-delimited
>     seems sufficent.
>         * The file's size

Why, just look at the file itself.

>         * XXX do we need to store permissions?  The owner/group?

No, this is a function of the OS and sysadmin's preferences; and it
only affects the run-time, not installation or removal.

>         * An MD5 digest of the file, written in hex.  (XXX All 16
>           bytes of the digest seems unnecessary; first 8 bytes only,
>           maybe?  Is a zlib.crc32() hash sufficient?)

What is the point of using only part of the MD5 digest?  How are you
supposed to tell if the file has changed (corrupted, trojaned or
tweaked) if you don't have a "fingerprint" of some sort (and if
8-bytes was good enough for that purpose, why does MD5 use 16)?

>         * The file's full path, as installed on the system.  (XXX
>           should it be relative to sys.prefix, or sys.prefix +
>           '/lib/python<version>?'  If so, full paths are still needed;
>           consider a package that installs a startup script such as
>           /etc/init.d/zope)

I think this is going down the wrong track, and it will take someone
familiar with Debian to construct a proper init script for me...
[more later]

>
>         * XXX some sort of type indicator, to indicate whether this is
>           a Python module, binary module, documentation file, config
>           file?  Do we need this?

Yes, for config files and docs at least.

>     A package that uses the Distutils for installation will
>     automatically update the database.  Packages that roll their own
>     installation
>
>     XXX what's the relationship between this database and the RPM or
>     DPKG database?  I'm tempted to make the Python database completely
>     optional; a distributor can preserve the interface of the package
>     management tool and replace it with their own wrapper on top of
>     their own package manager.  (XXX but how would the Distutils know
>     that, and not bother to update the Python database?)

...[the more] The install path will be dependent on the target
system.  Packages should be in a platform independent format, and
contain enough meta-data that they can be converted to the native
package format (I don't think distutils modules have enough meta-data
to accomplish this, but haven't been keeping up with it or PEP241).

Don't worry about the installation phase; let distutils convert from a
generic format (if necessary), then hand it off to dpkg, rpm, etc, or
install it itself for those that do not have a native package manager
yet (do a good enough job of this and it may even become the de facto
standard on those platforms).

I have an idea for this aspect... I'm gonna rewriting Debian's dh_make
(template based debianizing tool), moving all the code that extracts
information from the source into the templates themselves (working
title, "izer").  It should be possible to create any format of package
from a distutils module.  See...

	http://packages.debian.org/unstable/devel/dh-make.html

...for more about what this tool does,
and a link to the (perl) source.

The end result being...
The "Python database" will only exist for those platforms that do not
already have a package system, so you would not need to worry about
keeping the two in sync.


- Bruce



From guido@digicool.com  Wed Jul 11 10:02:04 2001
From: guido@digicool.com (Guido van Rossum)
Date: Wed Jul 11 09:02:04 2001
Subject: [Python-Dev] PEP 250 - site-packages on Windows: (Was: [Distutils] Package DB: strawman PEP)
In-Reply-To: Your message of "Wed, 11 Jul 2001 09:32:06 BST."
 <714DFA46B9BBD0119CD000805FC1F53B01B5AEDF@ukrux002.rundc.uk.origin-it.com>
References: <714DFA46B9BBD0119CD000805FC1F53B01B5AEDF@ukrux002.rundc.uk.origin-it.com>
Message-ID: <200107111302.f6BD2gP13353@odiug.digicool.com>

> 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?

[Paul Moore]
> 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...)

I just read that PEP over, and I agree with it.  I think it should be
implemented.  If anyone with sourceforge permission would like to
champion this PEP further (by implementing the modest change it
suggests so that it can be rolled out with Python 2.2a1 next week),
that would really help!

--Guido van Rossum (home page: http://www.python.org/~guido/)


From mats@laplaza.org  Wed Jul 11 10:10:01 2001
From: mats@laplaza.org (Mats Wichmann)
Date: Wed Jul 11 09:10:01 2001
Subject: [Distutils] Package DB: strawman PEP
In-Reply-To: <Pine.LNX.4.21.0107091411520.1770-100000@llave.eproinet.com
 >
References: <20010708234624.A30892@ute.cnri.reston.va.us>
Message-ID: <5.1.0.14.1.20010710220537.027b3f08@laplaza.org>

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.



From robin@jessikat.fsnet.co.uk  Wed Jul 11 10:54:01 2001
From: robin@jessikat.fsnet.co.uk (Robin Becker)
Date: Wed Jul 11 09:54:01 2001
Subject: PEP 250 - site-packages on Windows: (Was: [Distutils] Package DB:	 strawman PEP)
In-Reply-To: <714DFA46B9BBD0119CD000805FC1F53B01B5AEDF@ukrux002.rundc.uk.origin-it.com>
References: <714DFA46B9BBD0119CD000805FC1F53B01B5AEDF@ukrux002.rundc.uk.origin-it.com>
Message-ID: <6RS$zIAyoFT7Ewau@jessikat.fsnet.co.uk>

In article <714DFA46B9BBD0119CD000805FC1F53B01B5AEDF@ukrux002.rundc.uk.o
rigin-it.com>, Moore, Paul <Paul.Moore@atosorigin.com> writes
>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.
...
does this PEP address the location of .pyds and associated .dlls under
win32?

If I have several separate extensions which depend on common .dlls there
is always a problem under win32 if they go into separate areas. As I
understand it if the dll is in the same directory as the pyd that uses
it then all's well.

I have no objection to dlls and .dlls ending up in PYTHONROOT\lib\site-
packages, but what about the associated .libs (for dlls/pyds) and real
static .libs and where are we to install include files for exported
apis. I haven't any objection to following the unix model as closely as
possible, but what really stands out here is that the base install has
its own special directories for DLLs and Libs etc. The extensions are
really just extensions and could theoretically be installed or not.
-- 
Robin Becker


From Paul.Moore@atosorigin.com  Wed Jul 11 11:07:00 2001
From: Paul.Moore@atosorigin.com (Moore, Paul)
Date: Wed Jul 11 10:07:00 2001
Subject: PEP 250 - site-packages on Windows: (Was: [Distutils] Package
 DB: strawman PEP)
Message-ID: <714DFA46B9BBD0119CD000805FC1F53B01B5AEE5@ukrux002.rundc.uk.origin-it.com>

From: Robin Becker [mailto:robin@jessikat.fsnet.co.uk]
> does this PEP address the location of .pyds and associated .dlls
> under win32?

Yes. Read the PEP. It addresses it, by saying that nothing special will be
done.

> If I have several separate extensions which depend on common .dlls there
> is always a problem under win32 if they go into separate areas. As I
> understand it if the dll is in the same directory as the pyd that uses
> it then all's well.

The PEP doesn't address this problem - if it's a problem now, it won't be
fixed by the PEP. All the PEP does is make PYTHONROOT\lib\site-packages the
"preferred" location, instead of the current PYTHONROOT. Do you currently
put DLLs in PYTHONROOT? Probably not.

> I have no objection to dlls and .dlls ending up in PYTHONROOT\lib\site-
> packages, but what about the associated .libs (for dlls/pyds) and real
> static .libs and where are we to install include files for exported
> apis. I haven't any objection to following the unix model as closely as
> possible, but what really stands out here is that the base install has
> its own special directories for DLLs and Libs etc. The extensions are
> really just extensions and could theoretically be installed or not.

This is a valid issue, appropriate for consideration by the distutils-sig,
but it doesn't affect PEP 250. That PEP just alters the "root" location from
which a distributed package should hang. It doesn't have anything to say
about the internal organisation of that distribution, or about how the
distribution manages to locate its resources (DLLs, documentation, resource
files, whatever else).

Hope this helps,
Paul.


From pehr@eink.com  Wed Jul 11 12:07:00 2001
From: pehr@eink.com (Pehr Anderson)
Date: Wed Jul 11 11:07:00 2001
Subject: [Distutils] Distributing python applications
In-Reply-To: <1619.994466512@apathy.cs.washington.edu>; from tlau@ofb.net on Fri, Jul 06, 2001 at 05:41:52PM -0700
References: <1619.994466512@apathy.cs.washington.edu>
Message-ID: <20010711110637.G15482@eink.com>

Dear Tessa, 

This may be helpful. It is a setup.py file for solarwolf,
modified to setup a gnome icon and such.
I use "glob.glob" to grab the filenames of all the datafiles
in each subdirectory.  The script is installed in the right place 
as specified in my setup.cfg
Hope this helps! 

	-pehr


#!/usr/local/bin/python
  
#
# setup.py
#   This file requires python-2.1 to be installed
#   If you are using redhat-7.1 you must set your
#   ~/.bash_profile path such that it calls /usr/local/bin first.
#   Otherwise, you will not be able to build or install the rpm.
#   something like "export PATH=/usr/local/bin:$PATH"
#   Read more at http://python.org/sigs/distutils-sig/doc/
# 
DESCRIPTION = """\
Solarwolf is a remake of my childhood favorite, SolarFox, back on the
Atari 2600. It features quick and smooth fullscreen 800x600 graphics.
There is alpha transparent blitting, colorkeying, animated sprites,
scrolling starfield background, antialiased font rendering, and more.
The sound system supports multiple sound channel playback, along wiht
streming music support. It also supports input form keyboard or joystick.
"""

import glob,os,os.path,string
from distutils.core import setup
# get version data from code/game.py, must have code/__init__.py
import code.game

# Include our data files
#files = string.split(os.popen("find data -type f").read(),"\n")[:-1]
files = glob.glob('data/*')
files.remove('data/audio')
files.remove('data/music')
DATA_FILES = [
              ('data', files),
              ('data/audio', glob.glob('data/audio/*')),
              ('data/music', glob.glob('data/music/*')),
              ('/etc/X11/applnk/Games', ['solarwolf.desktop']),
             ]

setup ( name="solarwolf",
        version = code.game.version,
        license = "GPL",
        author = "Pete Shinners",
        author_email = "pete@shinners.org",
        url = "http://pygame.org",
        description = "A great game written using pygame",
        long_description = DESCRIPTION,
        packages = ['', 'code'],
        scripts = ['solarwolf'],
        data_files = DATA_FILES,
      )


#
# setup.cfg
#
  
[install]
install_lib=/usr/local/share/solarwolf
install_data=/usr/local/share/solarwolf
install_scripts=/usr/local/bin
  
[sdist]
formats = gztar


[bdist_rpm]
release = 1
packager = Pehr Anderson <pehr@alum.mit.edu>
provides = solarwolf
requires = python SDL pygame
distribution_name = redhat-7.1
doc_files =     lgpl.txt
                readme.txt

changelog =
  * Fri Jul 06 2001 Pehr Anderson <pehr@alum.mit.edu> 0.1.0-1
  - created setup using distutils for python 2.1 and redhat 7.1







On Fri, Jul 06, 2001 at 05:41:52PM -0700, Tessa Lau wrote:
> 
> 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
> 
> _______________________________________________
> Distutils-SIG maillist  -  Distutils-SIG@python.org
> http://mail.python.org/mailman/listinfo/distutils-sig

-- 
Pehr Anderson, E Ink Corporation, 617-499-6019, http://eink.com


From tlau@cs.washington.edu  Wed Jul 11 13:39:00 2001
From: tlau@cs.washington.edu (Tessa Lau)
Date: Wed Jul 11 12:39:00 2001
Subject: [Distutils] Problems with swig 1.3.6
In-Reply-To: Your message of Wed, 11 Jul 2001 11:06:37 EDT.
Message-ID: <23051.994869479@apathy.cs.washington.edu>

Hi all,

I just installed swig 1.3.6 (development version) and it no longer
appears to support the "-dnone" option used by distutils:

swigging src/bnc.i to src/bnc.c
swig -python -dnone -ISWIG -o src/bnc.c src/bnc.i
swig error : Unrecognized option -dnone
Use 'swig -help' for available options.
error: command 'swig' failed with exit status 1

One block of code I added to my setup.py script is to check whether
swig is present on a system.  If it's available, swig the interface
files, otherwise skip the swig step and build the .c files present in
the distribution.  (Unfortunately, everything fails if swig is present
but chokes on the command line you give it.)

Conditional swig invocation would be a great feature to add to distutils.

--Tessa


From thomas.heller@ion-tof.com  Wed Jul 11 16:14:03 2001
From: thomas.heller@ion-tof.com (Thomas Heller)
Date: Wed Jul 11 15:14:03 2001
Subject: [Python-Dev] PEP 250 - site-packages on Windows: (Was: [Distutils] Package DB: strawman PEP)
References: <714DFA46B9BBD0119CD000805FC1F53B01B5AEDF@ukrux002.rundc.uk.origin-it.com>  <200107111302.f6BD2gP13353@odiug.digicool.com>
Message-ID: <0e2e01c10a3d$6a950b40$e000a8c0@thomasnotebook>

> [Paul Moore]
> > 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...)
> 
> I just read that PEP over, and I agree with it.  I think it should be
> implemented.  If anyone with sourceforge permission would like to
> champion this PEP further (by implementing the modest change it
> suggests so that it can be rolled out with Python 2.2a1 next week),
> that would really help!
> 
> --Guido van Rossum (home page: http://www.python.org/~guido/)
If noone else shows up, I'll take it (hoping I find the time
for it).

Thomas




From slash@dotnetslash.net  Wed Jul 11 18:00:05 2001
From: slash@dotnetslash.net (Mark W. Alexander)
Date: Wed Jul 11 17:00:05 2001
Subject: [Distutils] Package DB: strawman PEP
In-Reply-To: <5.1.0.14.1.20010710220537.027b3f08@laplaza.org>
Message-ID: <Pine.LNX.4.21.0107111642190.8041-100000@llave.eproinet.com>

On Tue, 10 Jul 2001, Mats Wichmann wrote:

> 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.

Uhm, ok, I'll admit in my (non)Windows-bias that I didn't consider
_that_ one. Although in my ignorant defense, I have to ask: Does
Windows have what we've come to think of as a package manager? I know
there's information in the registry, and that an installer can check
to see if required dependencies are installed, but is there native
support to prevent the removal of those dependencies once the
dependent package is safely installed. In my experience, if there is,
it doesn't work.

The issue that I have is that when you go to manage software on a
machine, any time there is more than one place software information
may be stored you never know what's there unless you look in both.
Once you've got multiple places, automation goes out the window.
Building a python-specific module-manager is fine from a single-system
viewpoint, but in an enterprise with large numbers of heterogenous
systems, managing another repository on every machine is a nightmare.

Mark



From robin@jessikat.fsnet.co.uk  Wed Jul 11 21:03:01 2001
From: robin@jessikat.fsnet.co.uk (Robin Becker)
Date: Wed Jul 11 20:03:01 2001
Subject: [Distutils] Package DB: strawman PEP
In-Reply-To: <Pine.LNX.4.21.0107111642190.8041-100000@llave.eproinet.com>
References: <5.1.0.14.1.20010710220537.027b3f08@laplaza.org>
 <Pine.LNX.4.21.0107111642190.8041-100000@llave.eproinet.com>
Message-ID: <6qTPtgA1iOT7Ewpe@jessikat.fsnet.co.uk>

In article <Pine.LNX.4.21.0107111642190.8041-100000@llave.eproinet.com>,
Mark W. Alexander <slash@dotnetslash.net> writes
...
>Uhm, ok, I'll admit in my (non)Windows-bias that I didn't consider
>_that_ one. Although in my ignorant defense, I have to ask: Does
>Windows have what we've come to think of as a package manager? I know
>there's information in the registry, and that an installer can check
>to see if required dependencies are installed, but is there native
>support to prevent the removal of those dependencies once the
>dependent package is safely installed. In my experience, if there is,
>it doesn't work.
>
>The issue that I have is that when you go to manage software on a
>machine, any time there is more than one place software information
>may be stored you never know what's there unless you look in both.
>Once you've got multiple places, automation goes out the window.
>Building a python-specific module-manager is fine from a single-system
>viewpoint, but in an enterprise with large numbers of heterogenous
>systems, managing another repository on every machine is a nightmare.
>
>Mark
well there is stuff in the registry related to installations and shared
dlls have some kind of user count there too. There's also a registry
folder containing information about uninstall info.

In my Win2K for example I can't find python21.dll in the shared modules
list. Somewhere there must be an explanation of how and what is supposed
to be done by an installer.
-- 
Robin Becker


From tim.one@home.com  Thu Jul 12 02:24:01 2001
From: tim.one@home.com (Tim Peters)
Date: Thu Jul 12 01:24:01 2001
Subject: [Python-Dev] PEP 250 - site-packages on Windows: (Was: [Distutils] Package DB: strawman PEP)
In-Reply-To: <200107111302.f6BD2gP13353@odiug.digicool.com>
Message-ID: <LNBBLJKPBEHFEDALKOLCKENHKNAA.tim.one@home.com>

[Guido]
> I just read that PEP over, and I agree with it.  I think it should be
> implemented.  If anyone with sourceforge permission would like to
> champion this PEP further (by implementing the modest change it
> suggests so that it can be rolled out with Python 2.2a1 next week),
> that would really help!

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>).



From thomas.heller@ion-tof.com  Thu Jul 12 04:26:25 2001
From: thomas.heller@ion-tof.com (Thomas Heller)
Date: Thu Jul 12 03:26:25 2001
Subject: [Distutils] Package DB: strawman PEP
References: <5.1.0.14.1.20010710220537.027b3f08@laplaza.org> <Pine.LNX.4.21.0107111642190.8041-100000@llave.eproinet.com> <6qTPtgA1iOT7Ewpe@jessikat.fsnet.co.uk>
Message-ID: <0f9701c10aa3$c7618a90$e000a8c0@thomasnotebook>

From: "Robin Becker" <robin@jessikat.fsnet.co.uk>
> well there is stuff in the registry related to installations and shared
> dlls have some kind of user count there too. There's also a registry
> folder containing information about uninstall info.
> 
> In my Win2K for example I can't find python21.dll in the shared modules
> list. Somewhere there must be an explanation of how and what is supposed
> to be done by an installer.

All this is only a convention on windows, there is no package
manager enforcing these things.
- The registry contains reference counts of shared dlls,
the installers and uninstallers have to maintain them
and observe them.
- The registry contains some entries which will show up
in the add/remove programs control panel applet, and
a command line which will start the deinstaller.

The deinstaller itself has to be provided by the installer,
and the installer always has to feed the deinstaller with information
about files to delete, registry entries to remove, and so on.
The WISE installer, for example, has this information in the INSTALL.LOG
file, Installshield has something like uninst.isu, and so on.
bdist_wininst installers write 'Remove<package>.exe' as the uninstaller,
and '<package>-wininst.log' has the list of files and directories
installed.

(All this may be different with the new windows installer service, but
I don't know much about that)

Thomas



From mal@lemburg.com  Thu Jul 12 04:59:03 2001
From: mal@lemburg.com (M.-A. Lemburg)
Date: Thu Jul 12 03:59:03 2001
Subject: [Distutils] Re: [Python-Dev] PEP 250 - site-packages on Windows: (Was: [Distutils]
 Package DB: strawman PEP)
References: <LNBBLJKPBEHFEDALKOLCKENHKNAA.tim.one@home.com>
Message-ID: <3B4D587D.FDB733C0@lemburg.com>

Tim Peters wrote:
> 
> [Guido]
> > I just read that PEP over, and I agree with it.  I think it should be
> > implemented.  If anyone with sourceforge permission would like to
> > champion this PEP further (by implementing the modest change it
> > suggests so that it can be rolled out with Python 2.2a1 next week),
> > that would really help!
> 
> 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 ?

-- 
Marc-Andre Lemburg
CEO eGenix.com Software GmbH
______________________________________________________________________
Consulting & Company:                           http://www.egenix.com/
Python Software:                        http://www.lemburg.com/python/


From Paul.Moore@atosorigin.com  Thu Jul 12 05:34:03 2001
From: Paul.Moore@atosorigin.com (Moore, Paul)
Date: Thu Jul 12 04:34:03 2001
Subject: [Distutils] RE: [Python-Dev] PEP 250 - site-packages on Windows: (Was: [Distu
 tils]  Package DB: strawman PEP)
Message-ID: <714DFA46B9BBD0119CD000805FC1F53B01B5AEE9@ukrux002.rundc.uk.origin-it.com>

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
 


From mal@lemburg.com  Thu Jul 12 06:17:36 2001
From: mal@lemburg.com (M.-A. Lemburg)
Date: Thu Jul 12 05:17:36 2001
Subject: [Distutils] Re: [Python-Dev] PEP 250 - site-packages on Windows: (Was: [Distutils]
 Package DB: strawman PEP)
References: <714DFA46B9BBD0119CD000805FC1F53B01B5AEE9@ukrux002.rundc.uk.origin-it.com>
Message-ID: <3B4D6A7B.F493D611@lemburg.com>

"Moore, Paul" wrote:
> 
> 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.

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 ?
 
> 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

This doesn't seem to do the trick: the Windows installer still installs
the packages directly to \Python21.

-- 
Marc-Andre Lemburg
CEO eGenix.com Software GmbH
______________________________________________________________________
Consulting & Company:                           http://www.egenix.com/
Python Software:                        http://www.lemburg.com/python/


From Paul.Moore@atosorigin.com  Thu Jul 12 07:04:04 2001
From: Paul.Moore@atosorigin.com (Moore, Paul)
Date: Thu Jul 12 06:04:04 2001
Subject: [Distutils] RE: [Python-Dev] PEP 250 - site-packages on Windows: (Was: [Distu
 tils]   Package DB: strawman PEP)
Message-ID: <714DFA46B9BBD0119CD000805FC1F53B01B5AEEB@ukrux002.rundc.uk.origin-it.com>

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 wwwjessie@21cn.com  Thu Jul 12 07:44:01 2001
From: wwwjessie@21cn.com (wwwjessie@21cn.com)
Date: Thu Jul 12 06:44:01 2001
Subject: [Distutils] =?gb2312?B?xvPStcnPzfijrNK7sr21vc67KFlvdXIgb25saW5lIGNvbXBhbnkp?=
Message-ID: <34e5801c10ab9$aa2ce120$9300a8c0@ifood1gongxing>

This is a multi-part message in MIME format.

------=_NextPart_000_34E59_01C10AFC.B8502120
Content-Type: text/plain;
	charset="gb2312"
Content-Transfer-Encoding: base64

1/C+tLXEu+HUsaOsxPq6w6Oh0rzKs8a31tC5+s34t/7O8dDFz6K5qcT6ss6/vKO6ICANCg0K07XT
0NfUvLq1xM34yc+5q8u+o6zVucq+uavLvrL6xre6zbf+zvGjrMzhuN/G89K1vrrV+cGmLMT609DB
vdbW0aHU8aO6DQoNCjEvIM341b62qNbGIDxodHRwOi8vd3d3Lmlmb29kMS5jb20vYWJvdXR1cy9v
dXJzZXJ2aWNlcy93ZWIuYXNwPiAgOg0K19S8us6su6S4/NDCo6y53MDtx7DMqLrzzKijrLj5vt3G
89K10OjSqqOsvajBotfUvLq1xM34yc+5q8u+o6zK/b7dv+LEo7/pyM7E+tGh1PGjusnMx+nQxc+i
t6KyvCzN+MnPsvrGt9W5yr6jrL/Nu6e3/s7x1tDQxCzN+MnPubrO78+1zbMsv827p7nYDQrPtbnc
wO0szfjJz8LbzLMszfjJz7vh0unW0NDELM34yc/V0Ma4LM22xrHPtc2zLNfKwc/PwtTY1tDQxCzO
yr7ttfey6Swg1dCx6rLJubrPtc2zLLfDzsrV382zvMa31s72LCDBxMzsytIovbvB96GizLjF0Cmh
raGtDQoNCs/rwcu94sr9vt2/4sSjv+nR3cq+1tDQxKO/x+vBqs+1o7ogc2FsZXNAaWZvb2QxLmNv
bSA8bWFpbHRvOnNhbGVzQGlmb29kMS5jb20+DQqhobXnu7CjujA3NTUtMzc4NjMwOaGhz/rK27K/
yfLQob3jDQoNCjIvINK8zfjNqCA8aHR0cDovL29uZXQuaWZvb2QxLmNvbS8+DQot19TW+sq9vajN
+KOsstnX97zytaWjrLy0vai8tNPDo7q/ydW5yr4zMNXFu/K4/Lbg1dXGrKOs19TW+sq9zqy7pKOs
v8nL5sqxuPzQws28xqy6zc7E19bE2sjdo6zU2s/ft6KyvLL6xrfQxc+ioaK5q8u+tq/MrLXIo6zU
+cvNtv68trn6vMrT8sP7KA0KyOdodHRwOi8veW91cm5hbWUuaWZvb2QxLmNvbSmjrNPr0rzKs8a3
1tC5+s34KNKzw+bkr8DAwb/UwtPiMjAwzfK0zim99MPcway906OszOG438LyvNK6zbnLv823w87K
wb+jrLaoxtrK1bW90rzKsw0KxrfW0Ln6zfjM4bmptcS/zbun0OjH87rNssm5utDFz6Khow0KDQoN
Cg0KN9TCMzDI1cewyerH67KiuLa/7sq508PSvM34zaijrMzYsfDTxbvdvNszODAw1KovxOqjrNT5
y83M9cLrueO45rKiw+K30dTayrPGt9eo0rXU09a+v6+1x7mpo6zH86OstPrA7aOsus/X99DFz6IN
Cs/rwcu94rj8tuA/IKGhx+vBqs+1o7ogc2FsZXNAaWZvb2QxLmNvbSA8bWFpbHRvOnNhbGVzQGlm
b29kMS5jb20+DQqhobXnu7CjujA3NTUtMzc4NjMwOaGhoaHP+srbsr/J8tChveMNCrvyILfDzsrO
0sPHtcTN+NKzIDxodHRwOi8vd3d3Lmlmb29kMS5jb20vYWJvdXR1cy9vdXJzZXJ2aWNlcy9jcHNl
cnZpY2UuYXNwPg0KOnd3dy5pZm9vZDEuY29tDQoNCrvY1rSjqMfrtKvV5qO6MDc1NS0zMjM5MDQ3
u/K3orXn19PTyrz+o7ogc2FsZXNAaWZvb2QxLmNvbSA8bWFpbHRvOnNhbGVzQGlmb29kMS5jb20+
IKOpDQoNCqH1ILG+uavLvrbUzfjVvrao1sa40NDLyKShoaGhICAgICAgICAgICAgICAgICAgICAg
ofUgsb65q8u+ttTSvM34zai3/s7xuNDQy8ikDQoNCrmry77D+7PGo7pfX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX1/Bqs+1yMujul9fX19fX19fX19fX19fX19fXw0K
X19fX18gDQoNCrXnu7Cjul9fX19fX19fX19fX19fX19fX19fX7Sr1eajul9fX19fX19fX19fX19f
X19fX19fX19FLW1haWyjul9fX19fX19fX19fX19fX18NCl9fX19fXyANCg0K

------=_NextPart_000_34E59_01C10AFC.B8502120
Content-Type: text/html;
	charset="gb2312"
Content-Transfer-Encoding: base64

PEhUTUw+DQo8SEVBRD4NCjxUSVRMRT5VbnRpdGxlZCBEb2N1bWVudDwvVElUTEU+IDxNRVRBIEhU
VFAtRVFVSVY9IkNvbnRlbnQtVHlwZSIgQ09OVEVOVD0idGV4dC9odG1sOyBjaGFyc2V0PWdiMjMx
MiI+IA0KPC9IRUFEPg0KDQo8Qk9EWSBCR0NPTE9SPSIjRkZGRkZGIiBURVhUPSIjMDAwMDAwIj4N
CjxUQUJMRSBXSURUSD0iOTglIiBCT1JERVI9IjAiIENFTExTUEFDSU5HPSIwIiBDRUxMUEFERElO
Rz0iMCI+PFRSPjxURD48UCBDTEFTUz1Nc29Ob3JtYWwgU1RZTEU9J21hcmdpbi1yaWdodDotMTcu
ODVwdDtsaW5lLWhlaWdodDoxNTAlJz48Rk9OVCBTSVpFPSIyIj7X8L60tcS74dSxo6zE+rrDo6HS
vMqzxrfW0Ln6zfi3/s7x0MXPormpxPqyzr+8o7ombmJzcDs8L0ZPTlQ+IA0KPC9QPjxQIENMQVNT
PU1zb05vcm1hbCBTVFlMRT0nbWFyZ2luLXJpZ2h0Oi0xNy44NXB0O2xpbmUtaGVpZ2h0OjE1MCUn
PjxGT05UIFNJWkU9IjIiPtO109DX1Ly6tcTN+MnPuavLvqOs1bnKvrmry76y+sa3us23/s7xo6zM
4bjfxvPStb661fnBpizE+tPQwb3W1tGh1PGjujxCUj48QlI+MS8gDQo8QQ0KSFJFRj0iaHR0cDov
L3d3dy5pZm9vZDEuY29tL2Fib3V0dXMvb3Vyc2VydmljZXMvd2ViLmFzcCI+zfjVvrao1sY8L0E+
IDog19S8us6su6S4/NDCo6y53MDtx7DMqLrzzKijrLj5vt3G89K10OjSqqOsvajBotfUvLq1xM34
yc+5q8u+o6zK/b7dv+LEo7/pyM7E+tGh1PGjusnMx+nQxc+it6KyvCzN+MnPsvrGt9W5yr6jrL/N
u6e3/s7x1tDQxCzN+MnPubrO78+1zbMsv827p7nYz7W53MDtLM34yc/C28yzLM34yc+74dLp1tDQ
xCzN+MnP1dDGuCzNtsaxz7XNsyzXysHPz8LU2NbQ0MQszsq+7bX3suksIA0K1dCx6rLJubrPtc2z
LLfDzsrV382zvMa31s72LCDBxMzsytIovbvB96GizLjF0CmhraGtPC9GT05UPjwvUD48UCBDTEFT
Uz1Nc29Ob3JtYWwgU1RZTEU9J2xpbmUtaGVpZ2h0OjIwLjBwdCc+PEI+PEZPTlQgQ09MT1I9IiNG
RjAwMDAiPs/rwcu94sr9vt2/4sSjv+nR3cq+1tDQxKO/PC9GT05UPjwvQj48Rk9OVCBTSVpFPSIy
Ij7H68Gqz7WjujxBIEhSRUY9Im1haWx0bzpzYWxlc0BpZm9vZDEuY29tIj5zYWxlc0BpZm9vZDEu
Y29tPC9BPiANCqGhtee7sKO6MDc1NS0zNzg2MzA5oaHP+srbsr/J8tChveM8L0ZPTlQ+PC9QPjxQ
IENMQVNTPU1zb05vcm1hbCBTVFlMRT0nbGluZS1oZWlnaHQ6MjAuMHB0Jz48L1A+PFAgQ0xBU1M9
TXNvTm9ybWFsIFNUWUxFPSdsaW5lLWhlaWdodDoyMC4wcHQnPjxGT05UIFNJWkU9IjIiPjIvIA0K
PEEgSFJFRj0iaHR0cDovL29uZXQuaWZvb2QxLmNvbS8iPtK8zfjNqDwvQT4t19TW+sq9vajN+KOs
stnX97zytaWjrLy0vai8tNPDo7q/ydW5yr4zMNXFu/K4/Lbg1dXGrKOs19TW+sq9zqy7pKOsv8nL
5sqxuPzQws28xqy6zc7E19bE2sjdo6zU2s/ft6KyvLL6xrfQxc+ioaK5q8u+tq/MrLXIo6zU+cvN
tv68trn6vMrT8sP7KMjnaHR0cDovL3lvdXJuYW1lLmlmb29kMS5jb20po6zT69K8yrPGt9bQufrN
+CjSs8Pm5K/AwMG/1MLT4jIwMM3ytM4pvfTD3MGsvdOjrMzhuN/C8rzSus25y7/Nt8POysG/o6y2
qMbaytW1vdK8yrPGt9bQufrN+Mzhuam1xL/Nu6fQ6Mfzus2yybm60MXPoqGjPEJSPjwvRk9OVD48
L1A+PFAgQ0xBU1M9TXNvTm9ybWFsIFNUWUxFPSdtYXJnaW4tcmlnaHQ6LTE3Ljg1cHQ7bGluZS1o
ZWlnaHQ6MTUwJSc+PEZPTlQgU0laRT0iMiI+PEJSPjwvRk9OVD4gDQo8Qj48Rk9OVCBDT0xPUj0i
I0ZGMDAwMCI+NzwvRk9OVD48L0I+PEZPTlQgQ09MT1I9IiNGRjAwMDAiPjxCPtTCMzDI1cewyerH
67KiuLa/7sq508PSvM34zaijrMzYsfDTxbvdvNszODAw1KovxOqjrNT5y83M9cLrueO45rKiw+K3
0dTayrPGt9eo0rXU09a+v6+1x7mpo6zH86OstPrA7aOsus/X99DFz6I8L0I+PEJSPjwvRk9OVD4g
DQo8Rk9OVCBTSVpFPSIyIj7P68HLveK4/LbgPyChocfrwarPtaO6PEEgSFJFRj0ibWFpbHRvOnNh
bGVzQGlmb29kMS5jb20iPnNhbGVzQGlmb29kMS5jb208L0E+IA0KoaG157uwo7owNzU1LTM3ODYz
MDmhoaGhz/rK27K/yfLQob3jPEJSPjwvRk9OVD48Rk9OVCBTSVpFPSIyIj678jxBDQpIUkVGPSJo
dHRwOi8vd3d3Lmlmb29kMS5jb20vYWJvdXR1cy9vdXJzZXJ2aWNlcy9jcHNlcnZpY2UuYXNwIj63
w87KztLDx7XEzfjSszwvQT46d3d3Lmlmb29kMS5jb208L0ZPTlQ+PC9QPjxQIENMQVNTPU1zb05v
cm1hbCBTVFlMRT0nbGluZS1oZWlnaHQ6MjAuMHB0JyBBTElHTj0iTEVGVCI+PC9QPjxQIENMQVNT
PU1zb05vcm1hbCBBTElHTj1MRUZUIFNUWUxFPSdsaW5lLWhlaWdodDoyMC4wcHQnPjxGT05UIFNJ
WkU9IjIiPjxCPrvY1rSjqMfrtKvV5qO6MDc1NS0zMjM5MDQ3u/K3orXn19PTyrz+o7o8L0I+PEEN
CkhSRUY9Im1haWx0bzpzYWxlc0BpZm9vZDEuY29tIj5zYWxlc0BpZm9vZDEuY29tIDwvQT48Qj6j
qTwvQj48L0ZPTlQ+PC9QPjxQPjxGT05UIFNJWkU9IjIiPqH1IA0Ksb65q8u+ttTN+NW+tqjWxrjQ
0MvIpKGhoaEmbmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7IKH1ILG+uavLvrbU0rzN+M2ot/7O8bjQ0MvIpDwvRk9OVD48L1A+PFAgQ0xBU1M9TXNv
Tm9ybWFsIFNUWUxFPSdsaW5lLWhlaWdodDoyMC4wcHQnPjxGT05UIFNJWkU9IjIiPrmry77D+7PG
o7pfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX1/Bqs+1yMujul9f
X19fX19fX19fX19fX19fX19fX19fIA0KPEJSPiA8QlI+ILXnu7Cjul9fX19fX19fX19fX19fX19f
X19fX7Sr1eajul9fX19fX19fX19fX19fX19fX19fX19FLW1haWyjul9fX19fX19fX19fX19fX19f
X19fX18gDQo8L0ZPTlQ+PC9QPjxQIENMQVNTPU1zb05vcm1hbCBTVFlMRT0nbGluZS1oZWlnaHQ6
MjAuMHB0Jz48L1A+PC9URD48L1RSPjwvVEFCTEU+IA0KPC9CT0RZPg0KPC9IVE1MPg0K

------=_NextPart_000_34E59_01C10AFC.B8502120--


From thomas.heller@ion-tof.com  Thu Jul 12 07:58:04 2001
From: thomas.heller@ion-tof.com (Thomas Heller)
Date: Thu Jul 12 06:58:04 2001
Subject: [Python-Dev] PEP 250 - site-packages on Windows: (Was: [Distutils]   Package DB: strawman PEP)
References: <714DFA46B9BBD0119CD000805FC1F53B01B5AEEB@ukrux002.rundc.uk.origin-it.com>
Message-ID: <100d01c10ac1$6b7fd470$e000a8c0@thomasnotebook>

From: "Moore, Paul" <Paul.Moore@atosorigin.com>
> From: M.-A. Lemburg [mailto:mal@lemburg.com]
> > 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...)?
The sources are in CVS:
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/python/distutils/misc/

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?

There are probably some issues here.
Currently it installs the package into prefix,
and creates a prefix/Remove<xxx>.exe uninstaller, and
*appends* info about uninstallation into the prefix/<xxx>-wininst.log
file.
In the future (after PEP250) it should install the package into
prefix/lib/site-packages. Also for older Python versions?
Or only for the newer ones? Depending on the distutils' version
used to create the installer? Depending on the actual site.py file?
Hardcoding a version check (version >= 2.2') into the installer
doesn't seem so nice, but would probably do the correct thing.

Note that 'python setup.py install' requires distutils to be present
- the bdist_wininst installer does not.

Thomas



From mal@lemburg.com  Thu Jul 12 08:52:05 2001
From: mal@lemburg.com (M.-A. Lemburg)
Date: Thu Jul 12 07:52:05 2001
Subject: [Distutils] Re: [Python-Dev] PEP 250 - site-packages on Windows: (Was: [Distutils]
 Package DB: strawman PEP)
References: <714DFA46B9BBD0119CD000805FC1F53B01B5AEEB@ukrux002.rundc.uk.origin-it.com>
Message-ID: <3B4D8F2A.A1D54B9D@lemburg.com>

"Moore, Paul" wrote:
> 
> 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.

They should be in the CVS tree of Python on SourceForge.
 
> 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. 

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 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...)?

The sources for the Windows installer are on SourceForge CVS too (under the
distutils branch). I believe that Thomas Heller who wrote the installer
will know best what to do about this...

-- 
Marc-Andre Lemburg
CEO eGenix.com Software GmbH
______________________________________________________________________
Consulting & Company:                           http://www.egenix.com/
Python Software:                        http://www.lemburg.com/python/



From Paul.Moore@atosorigin.com  Thu Jul 12 08:59:03 2001
From: Paul.Moore@atosorigin.com (Moore, Paul)
Date: Thu Jul 12 07:59:03 2001
Subject: [Distutils] RE: [Python-Dev] PEP 250 - site-packages on Windows: (Was: [Distu
 tils]   Package DB: strawman PEP)
Message-ID: <714DFA46B9BBD0119CD000805FC1F53B01B5AEED@ukrux002.rundc.uk.origin-it.com>

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 Paul.Moore@atosorigin.com  Thu Jul 12 09:08:03 2001
From: Paul.Moore@atosorigin.com (Moore, Paul)
Date: Thu Jul 12 08:08:03 2001
Subject: [Distutils] RE: [Python-Dev] PEP 250 - site-packages on Windows: (Was: [Distu
 tils]    Package DB: strawman PEP)
Message-ID: <714DFA46B9BBD0119CD000805FC1F53B01B5AEEE@ukrux002.rundc.uk.origin-it.com>

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 thomas.heller@ion-tof.com  Thu Jul 12 09:52:04 2001
From: thomas.heller@ion-tof.com (Thomas Heller)
Date: Thu Jul 12 08:52:04 2001
Subject: [Python-Dev] PEP 250 - site-packages on Windows: (Was: [Distutils]   Package DB: strawman PEP)
References: <714DFA46B9BBD0119CD000805FC1F53B01B5AEED@ukrux002.rundc.uk.origin-it.com>
Message-ID: <115b01c10ad1$50ea9cc0$e000a8c0@thomasnotebook>

From: "Moore, Paul" <Paul.Moore@atosorigin.com>
> > 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.
Good idea. But remember that there is still Pythonware's distribution,
which does neither create nor require registry entries,
also if you compile from source they are not available.

OTOH, bdist_wininst installers currently do not recognize these
Python installations, which is probably the next bug.

> 
> > 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.
It's my fault, I'm afraid. Didn't think enough about these things
earlier.

> 
> Paul.
> 

Thomas
BTW: We should narrow the TO: and CC: fields in this discussion.
I'm receiving every message threefold. What would be appropriate?



From mal@lemburg.com  Thu Jul 12 10:47:08 2001
From: mal@lemburg.com (M.-A. Lemburg)
Date: Thu Jul 12 09:47:08 2001
Subject: [Distutils] RE: [Python-Dev] PEP 250 - site-packages on Windows:
 (Was: [Distutils]    Package DB: strawman PEP)
References: <714DFA46B9BBD0119CD000805FC1F53B01B5AEEE@ukrux002.rundc.uk.origin-it.com>
Message-ID: <3B4DAA4C.A6F0859D@lemburg.com>

"Moore, Paul" wrote:
> 
> 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...

There should be a tarball of the CVS archive available somewhere
on SF.
 
> > 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.

Well, site.py could be modified to set a symbol in the sys module
which could then be queried by distutils, e.g. sys.extinstallprefix.

Alternatively, distutils could be made to default to 
Lib\site-packages and then revert to Lib\ in case this directory
is not available.

BTW, I don't think that using Windows registry keys for determining the
installation path is a good idea -- this information should be kept
in the site.py or sitecustomize.py module for easy editing.

-- 
Marc-Andre Lemburg
CEO eGenix.com Software GmbH
______________________________________________________________________
Consulting & Company:                           http://www.egenix.com/
Python Software:                        http://www.lemburg.com/python/


From tim@digicool.com  Thu Jul 12 11:58:01 2001
From: tim@digicool.com (Tim Peters)
Date: Thu Jul 12 10:58:01 2001
Subject: [Python-Dev] PEP 250 - site-packages on Windows: (Was: [Distutils]  Package DB: strawman PEP)
In-Reply-To: <3B4D587D.FDB733C0@lemburg.com>
Message-ID: <BIEJKCLHCIOIHAGOKOLHIEIPCCAA.tim@digicool.com>

[MAL]
> Cool, but what about the changes needed in distutils to actually
> utilize the new directory

Be my guest -- don't know anything about that, and no time to learn.

> and the changes to the Windows installer to create the directory
> at installation time ?

OK, I'll look into that, although it doesn't seem necessary.



From thomas.heller@ion-tof.com  Thu Jul 12 12:12:04 2001
From: thomas.heller@ion-tof.com (Thomas Heller)
Date: Thu Jul 12 11:12:04 2001
Subject: [Distutils] RE: [Python-Dev] PEP 250 - site-packages on Windows:  (Was: [Distutils]    Package DB: strawman PEP)
References: <714DFA46B9BBD0119CD000805FC1F53B01B5AEEE@ukrux002.rundc.uk.origin-it.com> <3B4DAA4C.A6F0859D@lemburg.com>
Message-ID: <12c801c10ae4$e79d1fe0$e000a8c0@thomasnotebook>

[I've cut down the To: and CC: headers to olny include python-dev
and distutils]
> Well, site.py could be modified to set a symbol in the sys module
> which could then be queried by distutils, e.g. sys.extinstallprefix.
> 
> Alternatively, distutils could be made to default to 
> Lib\site-packages and then revert to Lib\ in case this directory
> is not available.
> 
> BTW, I don't think that using Windows registry keys for determining the
> installation path is a good idea -- this information should be kept
> in the site.py or sitecustomize.py module for easy editing.

The problem is that the 'installation path' information must be
loaded at run time by the windows installer, and it may not always
sucessful to embed python at run time and let python code retrieve it.
Remember the problems we had with Python2.0 on win95/98, when win32all
was not installed? The installer was not able to compile the installed
files to pyc/pyo because of this path bug.

Anyway, how does bdist-rpm does it? Should be the same problem
there...

Thomas



From trentm@ActiveState.com  Thu Jul 12 13:04:00 2001
From: trentm@ActiveState.com (Trent Mick)
Date: Thu Jul 12 12:04:00 2001
Subject: [Python-Dev] PEP 250 - site-packages on Windows: (Was: [Distutils]  Package DB: strawman PEP)
In-Reply-To: <BIEJKCLHCIOIHAGOKOLHIEIPCCAA.tim@digicool.com>; from tim@digicool.com on Thu, Jul 12, 2001 at 10:57:30AM -0400
References: <3B4D587D.FDB733C0@lemburg.com> <BIEJKCLHCIOIHAGOKOLHIEIPCCAA.tim@digicool.com>
Message-ID: <20010712090113.E10387@ActiveState.com>

On Thu, Jul 12, 2001 at 10:57:30AM -0400, Tim Peters wrote:
> > and the changes to the Windows installer to create the directory
> > at installation time ?
> 
> OK, I'll look into that, although it doesn't seem necessary.

I have to agree with Tim. If distutils is going to install a package to
site-packages then it should create the directory itself if it does not
exist. Certainly it should not fail if the directory does not exist.

Trent


-- 
Trent Mick
TrentM@ActiveState.com


From trentm@ActiveState.com  Thu Jul 12 13:10:00 2001
From: trentm@ActiveState.com (Trent Mick)
Date: Thu Jul 12 12:10:00 2001
Subject: [Distutils] RE: [Python-Dev] PEP 250 - site-packages on Windows: (Was: [Distu tils]   Package DB: strawman PEP)
In-Reply-To: <714DFA46B9BBD0119CD000805FC1F53B01B5AEEB@ukrux002.rundc.uk.origin-it.com>; from Paul.Moore@atosorigin.com on Thu, Jul 12, 2001 at 11:02:28AM +0100
References: <714DFA46B9BBD0119CD000805FC1F53B01B5AEEB@ukrux002.rundc.uk.origin-it.com>
Message-ID: <20010712090858.F10387@ActiveState.com>

On Thu, Jul 12, 2001 at 11:02:28AM +0100, Moore, Paul wrote:
> 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.

The ActivePython 2.1 installer *does* create <installdir>\Lib\site-packages
on Windows.


Trent

-- 
Trent Mick
TrentM@ActiveState.com


From mal@lemburg.com  Thu Jul 12 13:39:03 2001
From: mal@lemburg.com (M.-A. Lemburg)
Date: Thu Jul 12 12:39:03 2001
Subject: [Distutils] Re: [Python-Dev] PEP 250 - site-packages on Windows: (Was: [Distutils]
 Package DB: strawman PEP)
References: <3B4D587D.FDB733C0@lemburg.com> <BIEJKCLHCIOIHAGOKOLHIEIPCCAA.tim@digicool.com> <20010712090113.E10387@ActiveState.com>
Message-ID: <3B4DD291.7FB22BC6@lemburg.com>

Trent Mick wrote:
> 
> On Thu, Jul 12, 2001 at 10:57:30AM -0400, Tim Peters wrote:
> > > and the changes to the Windows installer to create the directory
> > > at installation time ?
> >
> > OK, I'll look into that, although it doesn't seem necessary.
> 
> I have to agree with Tim. If distutils is going to install a package to
> site-packages then it should create the directory itself if it does not
> exist. Certainly it should not fail if the directory does not exist.

I believe that it creates the directory (distutils has a make_path()
API for this), but having it there for testing would sure help
in figuring out what to do. Please keep in mind that distutils
has to work with Python versions 1.5.2, 2.0 and 2.1.

Also, I think that it is cleaner to have existing directories
on sys.path. Indeed, it may be worthwhile having Python eliminate
non-existing dirs at startup time (i.e. in site.py).

-- 
Marc-Andre Lemburg
CEO eGenix.com Software GmbH
______________________________________________________________________
Consulting & Company:                           http://www.egenix.com/
Python Software:                        http://www.lemburg.com/python/


From mal@lemburg.com  Thu Jul 12 13:44:03 2001
From: mal@lemburg.com (M.-A. Lemburg)
Date: Thu Jul 12 12:44:03 2001
Subject: [Distutils] RE: [Python-Dev] PEP 250 - site-packages on Windows:
 (Was: [Distutils]    Package DB: strawman PEP)
References: <714DFA46B9BBD0119CD000805FC1F53B01B5AEEE@ukrux002.rundc.uk.origin-it.com> <3B4DAA4C.A6F0859D@lemburg.com> <12c801c10ae4$e79d1fe0$e000a8c0@thomasnotebook>
Message-ID: <3B4DD3B8.8A176981@lemburg.com>

Thomas Heller wrote:
> 
> [I've cut down the To: and CC: headers to olny include python-dev
> and distutils]
> > Well, site.py could be modified to set a symbol in the sys module
> > which could then be queried by distutils, e.g. sys.extinstallprefix.
> >
> > Alternatively, distutils could be made to default to
> > Lib\site-packages and then revert to Lib\ in case this directory
> > is not available.
> >
> > BTW, I don't think that using Windows registry keys for determining the
> > installation path is a good idea -- this information should be kept
> > in the site.py or sitecustomize.py module for easy editing.
> 
> The problem is that the 'installation path' information must be
> loaded at run time by the windows installer, and it may not always
> sucessful to embed python at run time and let python code retrieve it.
> Remember the problems we had with Python2.0 on win95/98, when win32all
> was not installed? The installer was not able to compile the installed
> files to pyc/pyo because of this path bug.

Ok. Point taken (this time ;-).
 
> Anyway, how does bdist-rpm does it? Should be the same problem
> there...

bdist_rpm runs the Python interpreter to figure out the install
dirs, etc. at rpm build time. The paths are then hard-coded into
the rpm file.

-- 
Marc-Andre Lemburg
CEO eGenix.com Software GmbH
______________________________________________________________________
Consulting & Company:                           http://www.egenix.com/
Python Software:                        http://www.lemburg.com/python/


From fdrake@acm.org  Thu Jul 12 17:13:00 2001
From: fdrake@acm.org (Fred L. Drake, Jr.)
Date: Thu Jul 12 16:13:00 2001
Subject: [Distutils] Re: [Python-Dev] PEP 250 - site-packages on Windows: (Was: [Distutils]
 Package DB: strawman PEP)
In-Reply-To: <3B4DD291.7FB22BC6@lemburg.com>
References: <3B4D587D.FDB733C0@lemburg.com>
 <BIEJKCLHCIOIHAGOKOLHIEIPCCAA.tim@digicool.com>
 <20010712090113.E10387@ActiveState.com>
 <3B4DD291.7FB22BC6@lemburg.com>
Message-ID: <15182.1064.74187.737679@cj42289-a.reston1.va.home.com>

M.-A. Lemburg writes:
 > I believe that it creates the directory (distutils has a make_path()
 > API for this), but having it there for testing would sure help
 > in figuring out what to do. Please keep in mind that distutils
 > has to work with Python versions 1.5.2, 2.0 and 2.1.

  Yes; the os.path.isdir(...) seems the right test for this.

 > Also, I think that it is cleaner to have existing directories
 > on sys.path. Indeed, it may be worthwhile having Python eliminate
 > non-existing dirs at startup time (i.e. in site.py).

  It should be doing that now.  If not, please file a bug report and
assign it to me.


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at acm.org>
PythonLabs at Digital Creations



From tim@digicool.com  Thu Jul 12 17:24:23 2001
From: tim@digicool.com (Tim Peters)
Date: Thu Jul 12 16:24:23 2001
Subject: [Distutils] Re: [Python-Dev] PEP 250 - site-packages on Windows: (Was: [Distutils] Package DB: strawman PEP)
In-Reply-To: <3B4DD291.7FB22BC6@lemburg.com>
Message-ID: <BIEJKCLHCIOIHAGOKOLHMEKECCAA.tim@digicool.com>

FYI, I fiddled the Windows Wise install script to create

     Lib\site-packages\

Of course this only applies to PythonLabs Windows installers created at or
after 2.2a1.



From fdrake@acm.org  Thu Jul 12 17:49:24 2001
From: fdrake@acm.org (Fred L. Drake, Jr.)
Date: Thu Jul 12 16:49:24 2001
Subject: [Distutils] Re: [Python-Dev] PEP 250 - site-packages on
 Windows: (Was: [Distutils] Package DB: strawman PEP)
In-Reply-To: <15182.1064.74187.737679@cj42289-a.reston1.va.home.com>
References: <3B4D587D.FDB733C0@lemburg.com>
 <BIEJKCLHCIOIHAGOKOLHIEIPCCAA.tim@digicool.com>
 <20010712090113.E10387@ActiveState.com>
 <3B4DD291.7FB22BC6@lemburg.com>
 <15182.1064.74187.737679@cj42289-a.reston1.va.home.com>
Message-ID: <15182.3249.195312.99147@cj42289-a.reston1.va.home.com>

Fred L. Drake, Jr. writes:
 >   It should be doing that now.  If not, please file a bug report and
 > assign it to me.

  Nevermind.  It is a bug, and I'm about to check in the fix.


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at acm.org>
PythonLabs at Digital Creations



From tim@digicool.com  Thu Jul 12 18:24:01 2001
From: tim@digicool.com (Tim Peters)
Date: Thu Jul 12 17:24:01 2001
Subject: [Python-Dev] PEP 250 - site-packages on Windows: (Was: [Distutils]   Package DB: strawman PEP)
In-Reply-To: <714DFA46B9BBD0119CD000805FC1F53B01B5AEED@ukrux002.rundc.uk.origin-it.com>
Message-ID: <BIEJKCLHCIOIHAGOKOLHEEKICCAA.tim@digicool.com>

[Thomas Heller]
> 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?

[Moore, Paul]
> What does that key *mean*?

Mark Hammond documented it as being the directory into which Python is
installed; python.exe lives here.

> If it is the directory into which packages should get installed,

No; it's much older than the package mechanism <0.1 wink>.

> then bdist_wininst should keep doing what it does now, and the
> Python installer should be changed to put site-packages into that key.

Not its purpose.

> If, on the other hand, this key has a meaning elsewhere in Python,

Not in the PythonLabs distribution, but I expect Mark's Win32 extensions
make use of it.

> and changing it would cause a problem,

IMO, any change to the registry settings requires Mark Hammond's blessing.

> then I would say that this is a bug in the Windows Installer, which
> should use a key of its own.

Couldn't follow that one.

> 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,
> ...

If you have to use the registry, why not paste Lib/site-packages on to the
end of InstallPath and use that?



From thomas.heller@ion-tof.com  Fri Jul 13 05:28:05 2001
From: thomas.heller@ion-tof.com (Thomas Heller)
Date: Fri Jul 13 04:28:05 2001
Subject: [Python-Dev] PEP 250 - site-packages on Windows: (Was: [Distutils]   Package DB: strawman PEP)
References: <BIEJKCLHCIOIHAGOKOLHEEKICCAA.tim@digicool.com>
Message-ID: <027201c10b75$b18224a0$e000a8c0@thomasnotebook>

From: "Tim Peters" <tim@digicool.com>
> [Thomas Heller]
> > 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?
> 
> [Moore, Paul]
> > What does that key *mean*?
> 
> Mark Hammond documented it as being the directory into which Python is
> installed; python.exe lives here.
> 
> > If it is the directory into which packages should get installed,
> 
> No; it's much older than the package mechanism <0.1 wink>.
> 
Per _accident_ it is also the location (pre PEP250 time),
where packages should get installed.

> > 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,
> > ...
> 
> If you have to use the registry, why not paste Lib/site-packages on to the
> end of InstallPath and use that?
The problem is that the same wininst executable should behave differently
depending on the policy Python has chosen for the installation directory:
Python 2.1 and before: Use prefix, Python 2.2 (and higher) should use
prefix/lib/site-packages.
That's why I said a (very hacky) solution would be to simply check 
for the version number at install time.
A better solution would be to somehow query site.py at install time?

Thomas



From mal@lemburg.com  Fri Jul 13 09:06:10 2001
From: mal@lemburg.com (M.-A. Lemburg)
Date: Fri Jul 13 08:06:10 2001
Subject: [Distutils] Re: [Python-Dev] PEP 250 - site-packages on Windows: (Was: [Distutils]
 Package DB: strawman PEP)
References: <BIEJKCLHCIOIHAGOKOLHEEKICCAA.tim@digicool.com> <027201c10b75$b18224a0$e000a8c0@thomasnotebook>
Message-ID: <3B4EDE0A.5D7391D6@lemburg.com>

> [where to get the installation path from on Windows]
> 
> That's why I said a (very hacky) solution would be to simply check
> for the version number at install time.
> A better solution would be to somehow query site.py at install time?

Ideal would be looking at the sys module for e.g. sys.extinstallpath
(which site.py could set). Is the problem of not being able to
embed Python at install time really a problem ? After all, if
it doesn't work for the installer, how should it work at all
in a different setting...

Alternatively, the installer could also simply query the
install path from the user and suggest the sys.extinstallpath
dir as default.

The installer should also make sure that the sys.extinstallpath
is on the sys.path (if not, the Python user won't be able to
use the installed package and should be warned about this).

A totally different problem is that of upgrading from the
old installation (in Python21\) to a new one 
(in Python\Lib\site-packages)... but that one is on the extension
writer, I guess.

-- 
Marc-Andre Lemburg
CEO eGenix.com Software GmbH
______________________________________________________________________
Consulting & Company:                           http://www.egenix.com/
Python Software:                        http://www.lemburg.com/python/




From thomas.heller@ion-tof.com  Fri Jul 13 12:35:19 2001
From: thomas.heller@ion-tof.com (Thomas Heller)
Date: Fri Jul 13 11:35:19 2001
Subject: [Distutils] Possible solution for PEP250 and bdist_wininst
Message-ID: <025d01c10bb1$4c0f69c0$e000a8c0@thomasnotebook>

I have a possible solution for this problem.

(I'll use the name INSTALLPATH for installation directory stored
in the registry under the key
HKEY_LOCAL_MACHINE\Software\Python\PythonCore\<version>\InstallPath).

The bdist_wininst installer at _install_ time sets the PYTHONHOME
environment variable to INSTALLPATH, then loads the python dll
and retrieves the 'extinstallpath' attribute from the sys module:

    wwsprintf(buffer, "PYTHONHOME=%s", INSTALLPATH);
    _putenv(buffer);
    Py_SetProgramName(modulename);
    Py_Initialize();
    pextinstallpath = PySys_GetObject("extinstallpath");
    Py_Finalize();

If this is successful, the (string contents of) pextinstallpath
is appended to INSTALLPATH, and that will be the directory where
the package will be installed. If unsuccessful, INSTALLPATH will
be used as before.

I'm unsure about the change to site.py, but this should work:

diff -c -r1.26 site.py
*** site.py     2001/03/23 17:53:49     1.26
--- site.py     2001/07/13 15:32:27
***************
*** 140,153 ****
                                   "python" + sys.version[:3],
                                   "site-packages"),
                          makepath(prefix, "lib", "site-python")]
-         elif os.sep == ':':
-             sitedirs = [makepath(prefix, "lib", "site-packages")]
          else:
!             sitedirs = [prefix]
          for sitedir in sitedirs:
              if os.path.isdir(sitedir):
                  addsitedir(sitedir)

  # Define new built-ins 'quit' and 'exit'.
  # These are simply strings that display a hint on how to exit.
  if os.sep == ':':
--- 140,154 ----
                                   "python" + sys.version[:3],
                                   "site-packages"),
                          makepath(prefix, "lib", "site-python")]
          else:
!             sitedirs = [prefix, os.path.join(prefix, "lib", "site-packages")]
          for sitedir in sitedirs:
              if os.path.isdir(sitedir):
                  addsitedir(sitedir)

+ if os.sep == '\\':
+     sys.extinstallpath = os.path.join(sys.prefix, "lib", "site-packages")
+
  # Define new built-ins 'quit' and 'exit'.
  # These are simply strings that display a hint on how to exit.
  if os.sep == ':':

If anyone cares, I can post the diffs for the bdist_wininst sources.

Thomas



From thomas.heller@ion-tof.com  Fri Jul 13 12:48:04 2001
From: thomas.heller@ion-tof.com (Thomas Heller)
Date: Fri Jul 13 11:48:04 2001
Subject: [Distutils] Re: [Python-Dev] Possible solution for PEP250 and bdist_wininst
References: <025d01c10bb1$4c0f69c0$e000a8c0@thomasnotebook>
Message-ID: <02ee01c10bb2$c9460ce0$e000a8c0@thomasnotebook>

> I'm unsure about the change to site.py, but this should work:
This was wrong, of course. Sorry for the confusion, should simply be:

diff -c -r1.30 site.py
*** site.py     2001/07/12 21:08:33     1.30
--- site.py     2001/07/13 15:43:49
***************
*** 151,156 ****
--- 151,159 ----
              if os.path.isdir(sitedir):
                  addsitedir(sitedir)

+ if os.sep == ':':
+     sys.extinstallpath = os.path.join(sys.prefix, "lib", "site-packages")
+
  del dirs_in_sys_path

  # Define new built-ins 'quit' and 'exit'.

Thomas



From Paul.Moore@atosorigin.com  Fri Jul 13 12:49:05 2001
From: Paul.Moore@atosorigin.com (Moore, Paul)
Date: Fri Jul 13 11:49:05 2001
Subject: [Distutils] RE: Possible solution for PEP250 and bdist_wininst
Message-ID: <714DFA46B9BBD0119CD000805FC1F53B01B5AEF7@ukrux002.rundc.uk.origin-it.com>

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@ion-tof.com  Fri Jul 13 12:59:04 2001
From: thomas.heller@ion-tof.com (Thomas Heller)
Date: Fri Jul 13 11:59:04 2001
Subject: [Distutils] RE: Possible solution for PEP250 and bdist_wininst
References: <714DFA46B9BBD0119CD000805FC1F53B01B5AEF7@ukrux002.rundc.uk.origin-it.com>
Message-ID: <03fc01c10bb4$a2754de0$e000a8c0@thomasnotebook>

> 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.

This must be answered by other people, I only use windows.
If it would be exposed uniformly, probably distutils itself
should also use it.

Thomas



From mal@lemburg.com  Fri Jul 13 14:24:05 2001
From: mal@lemburg.com (M.-A. Lemburg)
Date: Fri Jul 13 13:24:05 2001
Subject: [Distutils] Re: Possible solution for PEP250 and bdist_wininst
References: <025d01c10bb1$4c0f69c0$e000a8c0@thomasnotebook>
Message-ID: <3B4F2DF6.85158478@lemburg.com>

Thomas Heller wrote:
> 
> I have a possible solution for this problem.
> 
> (I'll use the name INSTALLPATH for installation directory stored
> in the registry under the key
> HKEY_LOCAL_MACHINE\Software\Python\PythonCore\<version>\InstallPath).
> 
> The bdist_wininst installer at _install_ time sets the PYTHONHOME
> environment variable to INSTALLPATH, then loads the python dll
> and retrieves the 'extinstallpath' attribute from the sys module:
> 
>     wwsprintf(buffer, "PYTHONHOME=%s", INSTALLPATH);
>     _putenv(buffer);
>     Py_SetProgramName(modulename);
>     Py_Initialize();
>     pextinstallpath = PySys_GetObject("extinstallpath");
>     Py_Finalize();
> 
> If this is successful, the (string contents of) pextinstallpath
> is appended to INSTALLPATH, and that will be the directory where
> the package will be installed. If unsuccessful, INSTALLPATH will
> be used as before.

Sounds OK.
 
> I'm unsure about the change to site.py, but this should work:
> 
> diff -c -r1.26 site.py
> *** site.py     2001/03/23 17:53:49     1.26
> --- site.py     2001/07/13 15:32:27
> ***************
> *** 140,153 ****
>                                    "python" + sys.version[:3],
>                                    "site-packages"),
>                           makepath(prefix, "lib", "site-python")]
> -         elif os.sep == ':':
> -             sitedirs = [makepath(prefix, "lib", "site-packages")]
>           else:
> !             sitedirs = [prefix]
>           for sitedir in sitedirs:
>               if os.path.isdir(sitedir):
>                   addsitedir(sitedir)
> 
>   # Define new built-ins 'quit' and 'exit'.
>   # These are simply strings that display a hint on how to exit.
>   if os.sep == ':':
> --- 140,154 ----
>                                    "python" + sys.version[:3],
>                                    "site-packages"),
>                           makepath(prefix, "lib", "site-python")]
>           else:
> !             sitedirs = [prefix, os.path.join(prefix, "lib", "site-packages")]
>           for sitedir in sitedirs:
>               if os.path.isdir(sitedir):
>                   addsitedir(sitedir)
> 
> + if os.sep == '\\':
> +     sys.extinstallpath = os.path.join(sys.prefix, "lib", "site-packages")
> +

Why not do this for all platforms (which support site-packages) ?

-- 
Marc-Andre Lemburg
CEO eGenix.com Software GmbH
______________________________________________________________________
Consulting & Company:                           http://www.egenix.com/
Python Software:                        http://www.lemburg.com/python/


From thomas.heller@ion-tof.com  Fri Jul 13 15:04:04 2001
From: thomas.heller@ion-tof.com (Thomas Heller)
Date: Fri Jul 13 14:04:04 2001
Subject: [Distutils] Re: [Python-Dev] Re: Possible solution for PEP250 and bdist_wininst
References: <025d01c10bb1$4c0f69c0$e000a8c0@thomasnotebook> <3B4F2DF6.85158478@lemburg.com>
Message-ID: <050a01c10bc6$11e401b0$e000a8c0@thomasnotebook>

From: "M.-A. Lemburg" <mal@lemburg.com>
[about setting sys.extinstallpath in site.py]
> 
> Why not do this for all platforms (which support site-packages) ?
Would probably make sense. But in this case,
distutils should also use this setting.

Thomas



From pete@visionart.com  Fri Jul 13 16:49:10 2001
From: pete@visionart.com (Pete Shinners)
Date: Fri Jul 13 15:49:10 2001
Subject: [Distutils] mac distutils needs more work
References: <1619.994466512@apathy.cs.washington.edu>
Message-ID: <00df01c10bd4$fed8d500$f43f93cd@visionart.com>

there are still two main problems with the distutils for
macos (i believe osx is fine). this is all coming second,
hand, so sorry i can't provide straight details, i'll try
to do the best i can.

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.

anyways, that is the minor problem, since it can be
worked around. the next set of problems is the big one.

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.

the first part of the problem is that distutils does not
expand the paths for the library_dirs correctly. it does
work correctly for the include_dirs, so it just needs to
process the library_dirs in the exact same way. i've been
told this is just a 1-2 line fix.

the other problem might be a little more work, but again is
about 2 lines of fixes to the code. the metrowerks compiler
code forgets to include the list of libraries to link to when
building the project. it actually has everything it needs to
do it, it just forgets to actually add the library names in.
apparantly the libaries are just added into the project very
similarly to how source files are added into the project.


hopefully these changes can make it into the 2.2 release.
there's still a little time before the real 2.2 RC's, so
i'm not too worried. again, sorry i can't be more specific on
the details. it sounds like it should all be easy to get working,
but if it turns out to be difficult, i can pry up more details.




From jack@oratrix.nl  Fri Jul 13 19:56:01 2001
From: jack@oratrix.nl (Jack Jansen)
Date: Fri Jul 13 18:56:01 2001
Subject: [Distutils] mac distutils needs more work
In-Reply-To: Message by "Pete Shinners" <pete@visionart.com> ,
 Fri, 13 Jul 2001 12:49:57 -0700 , <00df01c10bd4$fed8d500$f43f93cd@visionart.com>
Message-ID: <20010713225514.4329C162E01@oratrix.oratrix.nl>

Recently, "Pete Shinners" <pete@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@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 


From gustav@morpheus.demon.co.uk  Sat Jul 14 13:53:05 2001
From: gustav@morpheus.demon.co.uk (Paul Moore)
Date: Sat Jul 14 12:53:05 2001
Subject: [Distutils] Building extensions with mingw
Message-ID: <37u0lt0ngjahp52usrn6m0c9dnl92in0sb@4ax.com>

I have ActiveState Python 2.1 (which I assume was built with MSVC), and I=
 am
trying to build an extension using the mingw compiler. When I try to =
build
(python setup.py build -c mingw32) I get a whole load of undefined =
references to
_imp__Py... symbols.

Presumably, I'm missing some sort of supporting import library to tell =
mingw
about Python - the question is, how do I get one? Or am I being naive in
assuming that I can use mingw to build extensions for a Python built with=
 MSVC?

Any suggestions would be gratefully accepted...

Paul.


From mal@lemburg.com  Sat Jul 14 14:14:01 2001
From: mal@lemburg.com (M.-A. Lemburg)
Date: Sat Jul 14 13:14:01 2001
Subject: [Distutils] Building extensions with mingw
References: <37u0lt0ngjahp52usrn6m0c9dnl92in0sb@4ax.com>
Message-ID: <3B507DF1.30CD1633@lemburg.com>


Paul Moore wrote:
> 
> I have ActiveState Python 2.1 (which I assume was built with MSVC), and I am
> trying to build an extension using the mingw compiler. When I try to build
> (python setup.py build -c mingw32) I get a whole load of undefined references to
> _imp__Py... symbols.
> 
> Presumably, I'm missing some sort of supporting import library to tell mingw
> about Python - the question is, how do I get one? Or am I being naive in
> assuming that I can use mingw to build extensions for a Python built with MSVC?
> 
> Any suggestions would be gratefully accepted...

No idea about mingw, but have you tried pointing it at the 
python21.lib in the libs/ subdir of the Python installation 
(perhaps distutils cannot find it) ?

-- 
Marc-Andre Lemburg
CEO eGenix.com Software GmbH
______________________________________________________________________
Consulting & Company:                           http://www.egenix.com/
Python Software:                        http://www.lemburg.com/python/


From kern@caltech.edu  Sun Jul 15 00:26:01 2001
From: kern@caltech.edu (Robert Kern)
Date: Sat Jul 14 23:26:01 2001
Subject: [Distutils] Building extensions with mingw
In-Reply-To: <37u0lt0ngjahp52usrn6m0c9dnl92in0sb@4ax.com>
References: <37u0lt0ngjahp52usrn6m0c9dnl92in0sb@4ax.com>
Message-ID: <20010714202519.A22477@myrddin.caltech.edu>

On Sat, Jul 14, 2001 at 05:56:45PM +0100, Paul Moore wrote:
> I have ActiveState Python 2.1 (which I assume was built with MSVC), and I am
> trying to build an extension using the mingw compiler. When I try to build
> (python setup.py build -c mingw32) I get a whole load of undefined references to
> _imp__Py... symbols.
> 
> Presumably, I'm missing some sort of supporting import library to tell mingw
> about Python - the question is, how do I get one? Or am I being naive in
> assuming that I can use mingw to build extensions for a Python built with MSVC?

No, you are not being naive. It is possible and quite easy with the Distutils.
What you need to do is make a mingw import library (python21.lib will not work.)
What I need to do is get some free time to make an import library and tidy up my
page on extending Python via mingw.

Grab http://starship.python.net/crew/kernr/mingw32/lib2def.py
and change all instances of the string "python15" with the string "python21",
and you should be able to run it over python21.lib to get libpython21.a to
link with. It requires the program nm from mingw, so be sure to have that on
your path. You should be able to use the pristine include files.

The script might have to be tweaked a little more to catch all of the symbols.
An (untested) alternative would be to use the pexports program from
http://prdownloads.sourceforge.net/mingwrep/altbinutils-pe-1.0.zip

I haven't used Windows in some time, so I've been lazy about updating
everything.

-- 
Robert Kern
kern@caltech.edu

"In the fields of hell where the grass grows high
 Are the graves of dreams allowed to die."
  -- Richard Harter


From gustav@morpheus.demon.co.uk  Sun Jul 15 09:41:00 2001
From: gustav@morpheus.demon.co.uk (Paul Moore)
Date: Sun Jul 15 08:41:00 2001
Subject: [Distutils] Why doesn't distutils respect the INCLUDE/LIB environment variable (MSVC)?
Message-ID: <8t23ltc2v2co2gf01ci2ainf8fhdqusbhh@4ax.com>

I'm trying to build an extension (Imaging) which depends on a number of =
external
libraries (JPEG, Zlib, Tk). Rather than hard code the locations of the =
libraries
in the setup.py, I set my INCLUDE and LIB environment variables so that =
MSVC
picks up the libraries automatically. Unfortunately, this doesn't seem to=
 work
properly, as distutils ignores these variables! Checking in the source, I=
 see
that this is deliberate (see get_msvc_paths and set_path_env_var in
msvccompiler.py).

I don't believe that this decision is correct - it leaves the user no =
way, short
of modifying the registry manually, to add include/library directories to=
 the
standard paths. So manually hacking setup.py becomes a necessity.

Can I suggest that msvccompiler.py *adds* the current entries to INCLUDE =
and
LIB, rather than replacing those variables completely. Or at least, that =
another
way of including include/library directories external to setup.py be
available...

Thanks,
Paul.


From gustav@morpheus.demon.co.uk  Sun Jul 15 09:56:00 2001
From: gustav@morpheus.demon.co.uk (Paul Moore)
Date: Sun Jul 15 08:56:00 2001
Subject: [Distutils] Building an intermediate library
Message-ID: <cj43lt4htp8ekl1hprbn92tq6cackrdmp7@4ax.com>

I have an extension which I am trying to build using distutils. There are=
 a
series of .c files in a subdirectory, and a couple of driver C files. The
subdirectory files should, ideally, be compiled and then built into a =
temporary
.lib file, which is then linked with the 2 individual driver files to =
create two
.pyd extensions. I can do the build by listing all of the subdirectory .c=
 files
in the build instructions for the 2 .pyds, but if I do this, the compiler=
 (MSVC)
doesn't seem to eliminate unused object files. So either I need to list =
exactly
the right .c files for each extension, or I build the intermediate .lib.

The problem is, I can't work out if it is possible to persuade distutils =
to
build an intermediate library like this. Is it possible? If so, can =
anyone point
me to any suitable examples of what to do? (Or alternatively, point me at=
 the
appropriate parts of the source, and appropriate example setup.py files, =
to
allow me to work out how to do this for myself.)

Thanks,
Paul.


From robin@jessikat.fsnet.co.uk  Sun Jul 15 10:05:01 2001
From: robin@jessikat.fsnet.co.uk (Robin Becker)
Date: Sun Jul 15 09:05:01 2001
Subject: [Distutils] Building an intermediate library
In-Reply-To: <cj43lt4htp8ekl1hprbn92tq6cackrdmp7@4ax.com>
References: <cj43lt4htp8ekl1hprbn92tq6cackrdmp7@4ax.com>
Message-ID: <B9oxYKAFTZU7EwGz@jessikat.fsnet.co.uk>

In article <cj43lt4htp8ekl1hprbn92tq6cackrdmp7@4ax.com>, Paul Moore <gustav@morpheus.demon.co.uk>
writes
>I have an extension which I am trying to build using distutils. There are a
>series of .c files in a subdirectory, and a couple of driver C files. The
>subdirectory files should, ideally, be compiled and then built into a temporary
>.lib file, which is then linked with the 2 individual driver files to create two
>.pyd extensions. I can do the build by listing all of the subdirectory .c files
>in the build instructions for the 2 .pyds, but if I do this, the compiler (MSVC)
>doesn't seem to eliminate unused object files. So either I need to list exactly
>the right .c files for each extension, or I build the intermediate .lib.
>
>The problem is, I can't work out if it is possible to persuade distutils to
>build an intermediate library like this. Is it possible? If so, can anyone point
>me to any suitable examples of what to do? (Or alternatively, point me at the
>appropriate parts of the source, and appropriate example setup.py files, to
>allow me to work out how to do this for myself.)
>
>Thanks,
>Paul.
...
here's what I'm using with distutils to try and build the imaging stuff
#!/usr/bin/env python
'''Distutils setup for FLundh's imaging library'''
import os, sys, string
from distutils.core import setup, Extension
from distutils.ccompiler import new_compiler

pyVer = string.split(sys.version)[0]
tclVer = pyVer>='1.6' and '83' or '82'
if sys.platform=="win32":
        _imaging_libs=['libImaging','libz','libjpeg','gdi32']
        _imagingtk_libs=['libImaging','tk'+tclVer,'tcl'+tclVer]
        TCL_LIBDIR='../../tcl'
        TCL_INCDIR='/tcl/include'
else:
        _imaging_libs=['Imaging','z','jpeg']
        _imagingtk_libs=['Imaging','tk'+tclVer,'tcl'+tclVer]

# Make sure the user has (configured and) built the C Imaging library.
# Take advantage of the Distutils bureaucracy to generate the filename
# of the library in a portable way.
compiler = new_compiler()
lib_file = os.path.join ("libImaging", compiler.library_filename (_imaging_libs[0]))
JPEGINC='../jpeg-6b'
ZLIBINC='../zlib-1.1.3'
libImagingSRCs=['libImaging\\%s.c'%x for x in string.split('''Access
Bands
BitDecode
Blend
Chops
Convert
ConvertYCbCr
Copy
Crc32
Crop
Dib
Draw
Effects
EpsEncode
Except
File
Fill
Filter
FliDecode
Geometry
GetBBox
GifDecode
GifEncode
HexDecode
Histo
JpegDecode
JpegEncode
LzwDecode
Matrix
MspDecode
Negative
Offset
Pack
PackDecode
Palette
Paste
Quant
QuantHash
QuantHeap
PcdDecode
PcxDecode
PcxEncode
Point
RawDecode
RawEncode
Storage
SunRleDecode
TgaRleDecode
Unpack
UnpackYCC
XbmDecode
XbmEncode
ZipDecode
ZipEncode''')]
_imaging_ext=Extension( '_imaging',
                                                ['_imaging.c', 'decode.c', 'encode.c', 'map.c', 'display.c', 'outline.c', 'path.c'],
                                                include_dirs = ['libImaging',JPEGINC,ZLIBINC],
                                                library_dirs= ['./libImaging'],
                                                libraries= _imaging_libs,
                                                )
_imagingtk_ext=Extension(       '_imagingtk',
                                                ['_imagingtk.c', 'Tk/tkImaging.c'],
                                                include_dirs = ['libImaging',TCL_INCDIR],
                                                library_dirs= ['./libImaging',TCL_LIBDIR],
                                                libraries= _imagingtk_libs,
                                                )

setup(  name = "PIL",
                version = "1.1.2",
                description = "Python Imaging Library",
                author = "Fredrik Lundh",
                author_email = "fredrik@pythonware.com",
                url = "http://www.pythonware.com/downloads.htm",
                packages = ['PIL'],
                libraries=      [('libImaging',
                                        {
                                        'sources':      libImagingSRCs,
                                        'include_dirs': [JPEGINC,ZLIBINC,],
                                        'macros': [],
                                        }
                                        ),
                                        ],
                ext_modules =   [_imaging_ext, _imagingtk_ext],
        )

if sys.platform=='win32' and ('install' in sys.argv or 'install_ext' in sys.argv):
        def MovePYDs(*F):
                for x in sys.argv:
                        if x[:18]=='--install-platlib=': return
                src = sys.exec_prefix
                dst = os.path.join(src,'DLLs')
                for f in F:
                        dstf = os.path.join(dst,f)
                        try:
                                os.remove(dstf)
                        except:
                                pass
                        os.rename(os.path.join(src,f),dstf)
        MovePYDs('_imaging.pyd','_imagingtk.pyd')

-- 
Robin Becker


From gustav@morpheus.demon.co.uk  Sun Jul 15 10:19:00 2001
From: gustav@morpheus.demon.co.uk (Paul Moore)
Date: Sun Jul 15 09:19:00 2001
Subject: [Distutils] Re: [Mingw-users] How to get an import lib from a DLL
In-Reply-To: <001001c10cb1$4ad6f270$6ae76882@pcpm.ucl.Ac.be>
References: <l1v0ltkvj89cbbshp2a010gaco3lagp0u2@4ax.com> <001001c10cb1$4ad6f270$6ae76882@pcpm.ucl.Ac.be>
Message-ID: <s853lt4t5dku6795cjch45oh0g4di58d68@4ax.com>

On Sun, 15 Jul 2001 00:06:53 +0200, you wrote:

>In the distutils section of the python documentation
>
>http://www.python.org/doc/current/inst/tweak-flags.html#SECTION000312000=
0000
>00000000
>
>you'll find a link to this page
[...]

Got it! Thanks - I was looking in the "Distributing Python Modules" =
document,
when I should have been looking in "Installing Python Modules".

Thanks for the pointer, I have it sorted now.
Paul.


From gustav@morpheus.demon.co.uk  Sun Jul 15 10:23:01 2001
From: gustav@morpheus.demon.co.uk (Paul Moore)
Date: Sun Jul 15 09:23:01 2001
Subject: [Distutils] Building an intermediate library
In-Reply-To: <B9oxYKAFTZU7EwGz@jessikat.fsnet.co.uk>
References: <cj43lt4htp8ekl1hprbn92tq6cackrdmp7@4ax.com> <B9oxYKAFTZU7EwGz@jessikat.fsnet.co.uk>
Message-ID: <5a63ltk9gg2jc3eqko24kiuffvm3qglf2a@4ax.com>

On Sun, 15 Jul 2001 14:04:05 +0100, Robin Becker wrote:

>here's what I'm using with distutils to try and build the imaging stuff
[...]

Woo. That looks like a good example. Thanks, I'll learn from this.... (As=
 the
library I was trying to build was PIL, I'll probably use it as it stands =
as well
:-)

Had you sent this to Fredrik? It would be nice to have PIL with a proper
distutils setup...

Thanks,
Paul.


From mal@lemburg.com  Sun Jul 15 15:10:39 2001
From: mal@lemburg.com (M.-A. Lemburg)
Date: Sun Jul 15 14:10:39 2001
Subject: [Distutils] Re: [Python-Dev] Re: Possible solution for PEP250 and bdist_wininst
References: <025d01c10bb1$4c0f69c0$e000a8c0@thomasnotebook> <3B4F2DF6.85158478@lemburg.com> <050a01c10bc6$11e401b0$e000a8c0@thomasnotebook>
Message-ID: <3B51DC46.6DD434F2@lemburg.com>

Thomas Heller wrote:
> 
> From: "M.-A. Lemburg" <mal@lemburg.com>
> [about setting sys.extinstallpath in site.py]
> >
> > Why not do this for all platforms (which support site-packages) ?
> Would probably make sense. But in this case,
> distutils should also use this setting.

Sure. (That was the point of inventing sys.extinstallpath ;-)

-- 
Marc-Andre Lemburg
CEO eGenix.com Software GmbH
______________________________________________________________________
Consulting & Company:                           http://www.egenix.com/
Python Software:                        http://www.lemburg.com/python/



From gustav@morpheus.demon.co.uk  Sun Jul 15 16:35:00 2001
From: gustav@morpheus.demon.co.uk (Paul Moore)
Date: Sun Jul 15 15:35:00 2001
Subject: [Distutils] Distutils enhancement - set variables from the command line
Message-ID: <fvg3ltsu2qht1n2tm07q2as159u541vsdr@4ax.com>

It would sometimes be nice for the user to be able to customise the setup
process without having to edit setup.py. The obvious case is to allow the=
 user
to override library directories, where setup.py can assume the "normal" =
case,
but still allow for non-standard locations.

One relatively simple approach would be to write setup.py to read a
configuration file, and get such options from there. But an alternative =
option
would be to allow setup.py to have access to (part of) the command line =
typed by
the user.

My suggestion would be to allow the "global_opts" or "cmdX_opts" to =
contain
arguments of the form key=3Dvalue. These can be exposed to setup.py as a
dictionary, say distutils.args.

What do people think?

Paul.


From robin@jessikat.fsnet.co.uk  Sun Jul 15 17:59:01 2001
From: robin@jessikat.fsnet.co.uk (Robin Becker)
Date: Sun Jul 15 16:59:01 2001
Subject: [Distutils] Building an intermediate library
In-Reply-To: <5a63ltk9gg2jc3eqko24kiuffvm3qglf2a@4ax.com>
References: <cj43lt4htp8ekl1hprbn92tq6cackrdmp7@4ax.com>
 <B9oxYKAFTZU7EwGz@jessikat.fsnet.co.uk>
 <5a63ltk9gg2jc3eqko24kiuffvm3qglf2a@4ax.com>
Message-ID: <c03mqJA6OgU7Ew1A@jessikat.fsnet.co.uk>

In article <5a63ltk9gg2jc3eqko24kiuffvm3qglf2a@4ax.com>, Paul Moore
<gustav@morpheus.demon.co.uk> writes
>On Sun, 15 Jul 2001 14:04:05 +0100, Robin Becker wrote:
>
>>here's what I'm using with distutils to try and build the imaging stuff
>[...]
>
>Woo. That looks like a good example. Thanks, I'll learn from this.... (As the
>library I was trying to build was PIL, I'll probably use it as it stands as well
>:-)
>
>Had you sent this to Fredrik? It would be nice to have PIL with a proper
>distutils setup...
I know there are problems with Solaris and this script so I'll wait a
bit.
-- 
Robin Becker


From wwwjessie@21cn.com  Mon Jul 16 08:09:08 2001
From: wwwjessie@21cn.com (wwwjessie@21cn.com)
Date: Mon Jul 16 07:09:08 2001
Subject: [Distutils] =?gb2312?B?tPPBrC0yMDAxxOq5+rzKwszJq8qzxrfT68jLwOC9ob+1sqnAwLvhKA==?=	=?gb2312?B?QWdybyBBbm51YWwgTWVldGluZyBDaGluYSAyMDAxKQ0=?=
Message-ID: <2d8c401c10ddc$547d0450$9300a8c0@ifood1gongxing>

This is a multi-part message in MIME format.

------=_NextPart_000_2D8C5_01C10E1F.62A04450
Content-Type: text/plain;
	charset="gb2312"
Content-Transfer-Encoding: base64

MjAwMcTq1tC5+rn6vMrFqdK1v8a8vMTqu+ENCrn6vMrCzMmryrPGt9PryMvA4L2hv7WyqcDAu+G8
sNGnyvXM1sLbu+ENCg0KCQ0K1bnG2qO6IAmhoTIwMDHE6jnUwjTI1S03yNUJDQq12LXjo7ogCaGh
tPPBrNDHuqO74dW51tDQxAkNCtb3sOyjuiAJoaHW0LuqyMvD8bmyus25+sWp0rWyvw0KoaHW0Ln6
v8bRp7y8yvXQrbvhDQqhobTzwazK0MjLw/HV/riuDQoJDQqz0LDso7ogCaGh1tC5+sLMyavKs8a3
t6LVudbQ0MQNCqGh1tC5+sWp0ae74Q0KoaHW0Ln6wszJq8qzxrfQrbvhDQqhobTzwazK0MWp0rW+
1g0KoaG088Gs0Me6o7vh1bnW0NDEDQoJDQrN+MLnt/7O8czhuanJzKO60rzKs8a31tC5+s34IGh0
dHA6Ly93d3cuaWZvb2QxLmNvbQ0KPGh0dHA6Ly93d3cuaWZvb2QxLmNvbS9pbmRleC5hc3A/ZnI9
ZGlzdHV0aWxzLXNpZ0BweXRob24ub3JnPiAJDQogCQ0Kofogzai5/dK8yrPGt9bQufrN+LGow/uy
ztW5o7q+xdXb08W73SixyMjnz9bT0MO/uPYgM00gWCAzTSC1xLHq17zVuc671K2821JNQjQ1MDCj
rM2ouf3O0sPH1rvQ6Li2Uk1CNDA1MCmjrA0KsajD+73Y1rnI1cbaMjAwMcTqN9TCMjDI1SA8aHR0
cDovL2dyZWVuMjAwMS5pZm9vZDEuY29tL2Zyb20xLmFzcD4gDQqh+iC7ttOtIMPit9HXorLhIDxo
dHRwOi8vd3d3Lmlmb29kMS5jb20vc2lnbnVwL3NldmFncmVlbS5hc3A+ILPJzqq5q8u+u+HUsaGj
DQo31MIyMMjVx7DXorLho6zE+r2r1No31MIyNcjVx7DNqLn9tefX09PKvP63vcq9w+K30bvxtcMz
MMz1ssm5utDFz6Khow0KyOe5+8T6srvP68rVtb3O0sPHtcTTyrz+o6zH6yDBqs+1ztLDxyA8bWFp
bHRvOnVuc3Vic2NyaWJlQGlmb29kMS5jb20+IKOsztLDx9LUuvO9q7K71Nm3otPKvP64+MT6oaMN
CrLp0a+juiBzYWxlc0BpZm9vZDEuY29tIDxtYWlsdG86c2FsZXNAaWZvb2QxLmNvbT4gIKGhoaG1
57uwo7owNzU1LTM3ODYzMDmhoc/6ytuyvw0KyfLQob3jILbFz8jJ+g0KDQoNCiANCg0Ku9gg1rQg
o6jH67Sr1eajujA3NTUtMzIzOTA0N7vyILeitefX09PKvP6juiBzYWxlc0BpZm9vZDEuY29tIDxt
YWlsdG86c2FsZXNAaWZvb2QxLmNvbT4NCqOpCQ0KofUgsb65q8u+09DS4s2ouf3SvMqzxrfW0Ln6
zfiyztW5IKGhoaEgofUgsb65q8u+xOK9+NK7sr3By73iuMOyqcDAu+GjrMfr0+vO0sPHwarPtQ0K
DQq5q8u+w/uzxqO6X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCsGqz7XI
y6O6X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0Ktee7sKO6X19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KtKvV5qO6X19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fXw0KRS1tYWlso7pfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fDQoJDQogCQ0KIAkNCiAJDQogCQ0KIAkNCg==

------=_NextPart_000_2D8C5_01C10E1F.62A04450
Content-Type: text/html;
	charset="gb2312"
Content-Transfer-Encoding: base64

PGh0bWw+DQo8aGVhZD4NCjx0aXRsZT5VbnRpdGxlZCBEb2N1bWVudDwvdGl0bGU+IDxtZXRhIGh0
dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PWdiMjMx
MiI+IA0KPHN0eWxlIHR5cGU9InRleHQvY3NzIj4NCjwhLS0NCnRkIHsgIGxpbmUtaGVpZ2h0OiAy
NHB4fQ0KLS0+DQo8L3N0eWxlPiANCjwvaGVhZD4NCg0KPGJvZHkgYmdjb2xvcj0iI0ZGRkZGRiIg
dGV4dD0iIzAwMDAwMCI+DQo8ZGl2IGFsaWduPSJDRU5URVIiPjx0YWJsZSB3aWR0aD0iNzUlIiBi
b3JkZXI9IjAiIGNlbGxzcGFjaW5nPSIwIiBjZWxscGFkZGluZz0iMCI+PHRyPjx0ZCBhbGlnbj0i
Q0VOVEVSIj48YSBocmVmPSJodHRwOy8vZ3JlZW4yMDAxLmlmb29kMS5jb20iPjxiPjIwMDHE6tbQ
ufq5+rzKxanStb/GvLzE6rvhPGJyPrn6vMrCzMmryrPGt9PryMvA4L2hv7WyqcDAu+G8sNGnyvXM
1sLbu+E8L2I+PC9hPjxicj48YnI+PC90ZD48L3RyPjx0cj48dGQgYWxpZ249IkNFTlRFUiI+PHRh
YmxlIHdpZHRoPSI3NSUiIGJvcmRlcj0iMCIgY2VsbHNwYWNpbmc9IjAiIGNlbGxwYWRkaW5nPSIw
Ij48dHI+PHRkIGhlaWdodD0iMTIiIHdpZHRoPSIzOSUiIGFsaWduPSJSSUdIVCI+PGI+PGZvbnQg
c2l6ZT0iMiI+1bnG2qO6IA0KPC9mb250PjwvYj48L3RkPjx0ZCBoZWlnaHQ9IjEyIiB3aWR0aD0i
NjElIj48Zm9udCBzaXplPSIyIj6hoTIwMDHE6jnUwjTI1S03yNU8L2ZvbnQ+PC90ZD48L3RyPjx0
cj48dGQgaGVpZ2h0PSIxMiIgd2lkdGg9IjM5JSIgYWxpZ249IlJJR0hUIj48Yj48Zm9udCBzaXpl
PSIyIj612LXjo7ogDQo8L2ZvbnQ+PC9iPjwvdGQ+PHRkIGhlaWdodD0iMTIiIHdpZHRoPSI2MSUi
Pjxmb250IHNpemU9IjIiPqGhtPPBrNDHuqO74dW51tDQxDwvZm9udD48L3RkPjwvdHI+PHRyPjx0
ZCBoZWlnaHQ9IjEyIiB3aWR0aD0iMzklIiBhbGlnbj0iUklHSFQiIHZhbGlnbj0iVE9QIj48Yj48
Zm9udCBzaXplPSIyIj7W97Dso7ogDQo8L2ZvbnQ+PC9iPjwvdGQ+PHRkIGhlaWdodD0iMTIiIHdp
ZHRoPSI2MSUiPjxmb250IHNpemU9IjIiPqGhPC9mb250Pjxmb250IHNpemU9IjIiPtbQu6rIy8Px
ubK6zbn6xanStbK/PGJyPqGh1tC5+r/G0ae8vMr10K274Txicj6hobTzwazK0MjLw/HV/riuPGJy
PjwvZm9udD48L3RkPjwvdHI+PHRyPjx0ZCBoZWlnaHQ9IjEyIiB3aWR0aD0iMzklIiBhbGlnbj0i
UklHSFQiIHZhbGlnbj0iVE9QIj48Yj48Zm9udCBzaXplPSIyIj6z0LDso7ogDQo8L2ZvbnQ+PC9i
PjwvdGQ+PHRkIGhlaWdodD0iMTIiIHdpZHRoPSI2MSUiPjxmb250IHNpemU9IjIiPqGhPC9mb250
Pjxmb250IHNpemU9IjIiPtbQufrCzMmryrPGt7ei1bnW0NDEPGJyPqGh1tC5+sWp0ae74Txicj6h
odbQufrCzMmryrPGt9Ctu+E8YnI+oaG088GsytDFqdK1vtY8YnI+oaG088Gs0Me6o7vh1bnW0NDE
PGJyPjwvZm9udD48L3RkPjwvdHI+PHRyPjx0ZCBjb2xzcGFuPSIyIiBhbGlnbj0iQ0VOVEVSIj48
Zm9udCBzaXplPSIyIj7N+MLnt/7O8czhuanJzKO60rzKs8a31tC5+s34IA0KPGEgaHJlZj0iaHR0
cDovL3d3dy5pZm9vZDEuY29tL2luZGV4LmFzcD9mcj1kaXN0dXRpbHMtc2lnQHB5dGhvbi5vcmci
Pmh0dHA6Ly93d3cuaWZvb2QxLmNvbTwvYT48L2ZvbnQ+PC90ZD48L3RyPjx0cj48dGQgY29sc3Bh
bj0iMiIgYWxpZ249IkNFTlRFUiI+Jm5ic3A7PC90ZD48L3RyPjx0cj48dGQgY29sc3Bhbj0iMiIg
YWxpZ249IkxFRlQiPjxwPjxmb250IHNpemU9IjIiPqH6IA0Kzai5/dK8yrPGt9bQufrN+LGow/uy
ztW5o7o8Yj48Zm9udCBzaXplPSIzIiBjb2xvcj0iI0ZGMDAwMCI+vsXV29PFu908L2ZvbnQ+PC9i
PiixyMjnz9bT0MO/uPYgM00gWCAzTSANCrXEserXvNW5zrvUrbzbUk1CNDUwMKOszai5/c7Sw8fW
u9DouLZSTUI0MDUwKaOsIDxhIGhyZWY9Imh0dHA6Ly9ncmVlbjIwMDEuaWZvb2QxLmNvbS9mcm9t
MS5hc3AiPjxiPjxmb250IHNpemU9IjMiIGNvbG9yPSIjRkYwMDAwIj6xqMP7vdjWucjVxtoyMDAx
xOo31MIyMMjVPC9mb250PjwvYj48L2E+PGJyPqH6IA0Ku7bTrTxhIGhyZWY9Imh0dHA6Ly93d3cu
aWZvb2QxLmNvbS9zaWdudXAvc2V2YWdyZWVtLmFzcCI+w+K30deisuE8L2E+s8nOqrmry7674dSx
oaMgPGZvbnQgY29sb3I9IiNGRjAwMDAiPjxiPjxmb250IHNpemU9IjMiPjfUwjIwyNXHsNeisuGj
rMT6vavU2jfUwjI1yNXHsM2ouf2159fT08q8/re9yr3D4rfRu/G1wzMwzPWyybm60MXPoqGjPC9m
b250PjwvYj48L2ZvbnQ+PGJyPsjnufvE+rK7z+vK1bW9ztLDx7XE08q8/qOsx+s8YSBocmVmPSJt
YWlsdG86dW5zdWJzY3JpYmVAaWZvb2QxLmNvbSI+warPtc7Sw8c8L2E+o6zO0sPH0tS6872rsrvU
2bei08q8/rj4xPqhozxicj6y6dGvo7o8YSBocmVmPSJtYWlsdG86c2FsZXNAaWZvb2QxLmNvbSI+
c2FsZXNAaWZvb2QxLmNvbTwvYT4gDQqhoaGhtee7sKO6MDc1NS0zNzg2MzA5oaHP+srbsr8gyfLQ
ob3jILbFz8jJ+jxicj48L2ZvbnQ+PC9wPjxwPiZuYnNwOzwvcD48L3RkPjwvdHI+PHRyPjx0ZCBo
ZWlnaHQ9IjMwIiBjb2xzcGFuPSIyIiBhbGlnbj0iQ0VOVEVSIj48Zm9udCBzaXplPSIyIj48Yj67
2CANCta0IKOox+u0q9Xmo7owNzU1LTMyMzkwNDe78iC3orXn19PTyrz+o7ogPGEgaHJlZj0ibWFp
bHRvOnNhbGVzQGlmb29kMS5jb20iPnNhbGVzQGlmb29kMS5jb208L2E+IA0Ko6k8L2I+PC9mb250
PjwvdGQ+PC90cj48dHI+PHRkIGhlaWdodD0iMTIiIGNvbHNwYW49IjIiPjxmb250IHNpemU9IjIi
PqH1ILG+uavLvtPQ0uLNqLn90rzKs8a31tC5+s34ss7VuSANCqGhoaEgofUgsb65q8u+xOK9+NK7
sr3By73iuMOyqcDAu+GjrMfr0+vO0sPHwarPtTxicj48YnI+uavLvsP7s8ajul9fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPsGqz7XIy6O6X19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fXzxicj48L2ZvbnQ+PGZvbnQgc2l6ZT0iMiI+tee7sKO6X19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj60q9Xmo7pfX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fPGJyPkUtbWFpbKO6X19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fXzxicj48L2ZvbnQ+PC90ZD48L3RyPjx0cj48dGQgaGVpZ2h0PSIxMiIgY29s
c3Bhbj0iMiIgYWxpZ249IkxFRlQiPiZuYnNwOzwvdGQ+PC90cj48dHI+PHRkIGhlaWdodD0iMTIi
IGNvbHNwYW49IjIiIGFsaWduPSJMRUZUIj4mbmJzcDs8L3RkPjwvdHI+PHRyPjx0ZCBoZWlnaHQ9
IjEyIiBjb2xzcGFuPSIyIiBhbGlnbj0iTEVGVCI+Jm5ic3A7PC90ZD48L3RyPjwvdGFibGU+PC90
ZD48L3RyPjx0cj48dGQ+Jm5ic3A7PC90ZD48L3RyPjx0cj48dGQ+Jm5ic3A7PC90ZD48L3RyPjwv
dGFibGU+PC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo=

------=_NextPart_000_2D8C5_01C10E1F.62A04450--


From mal@lemburg.com  Mon Jul 16 09:30:00 2001
From: mal@lemburg.com (M.-A. Lemburg)
Date: Mon Jul 16 08:30:00 2001
Subject: [Distutils] Distutils enhancement - set variables from the command
 line
References: <fvg3ltsu2qht1n2tm07q2as159u541vsdr@4ax.com>
Message-ID: <3B52DE57.7DE6DA8E@lemburg.com>

Paul Moore wrote:
> 
> It would sometimes be nice for the user to be able to customise the setup
> process without having to edit setup.py. The obvious case is to allow the user
> to override library directories, where setup.py can assume the "normal" case,
> but still allow for non-standard locations.
> 
> One relatively simple approach would be to write setup.py to read a
> configuration file, and get such options from there. But an alternative option
> would be to allow setup.py to have access to (part of) the command line typed by
> the user.
> 
> My suggestion would be to allow the "global_opts" or "cmdX_opts" to contain
> arguments of the form key=value. These can be exposed to setup.py as a
> dictionary, say distutils.args.
> 
> What do people think?

Doesn't setup.cfg provide enough means for the user to customize the
distutils behaviour ?

-- 
Marc-Andre Lemburg
CEO eGenix.com Software GmbH
______________________________________________________________________
Consulting & Company:                           http://www.egenix.com/
Python Software:                        http://www.lemburg.com/python/


From mal@lemburg.com  Mon Jul 16 09:39:01 2001
From: mal@lemburg.com (M.-A. Lemburg)
Date: Mon Jul 16 08:39:01 2001
Subject: [Distutils] Why doesn't distutils respect the INCLUDE/LIB
 environment variable (MSVC)?
References: <8t23ltc2v2co2gf01ci2ainf8fhdqusbhh@4ax.com>
Message-ID: <3B52E014.19D90750@lemburg.com>

Paul Moore wrote:
> 
> I'm trying to build an extension (Imaging) which depends on a number of external
> libraries (JPEG, Zlib, Tk). Rather than hard code the locations of the libraries
> in the setup.py, I set my INCLUDE and LIB environment variables so that MSVC
> picks up the libraries automatically. Unfortunately, this doesn't seem to work
> properly, as distutils ignores these variables! Checking in the source, I see
> that this is deliberate (see get_msvc_paths and set_path_env_var in
> msvccompiler.py).

I don't see any mention of the reasoning behind not looking
at the OS env vars in sources.
 
> I don't believe that this decision is correct - it leaves the user no way, short
> of modifying the registry manually, to add include/library directories to the
> standard paths. So manually hacking setup.py becomes a necessity.
> 
> Can I suggest that msvccompiler.py *adds* the current entries to INCLUDE and
> LIB, rather than replacing those variables completely. Or at least, that another
> way of including include/library directories external to setup.py be
> available...

Sounds reasonable. 

I don't know about the convention for looking up parameters
on Windows: do env vars override settings in the registry
or the other way around ?

Depending on what the standard procedure is on Windows, I'd
suggest to either prepend or append the env var settings to the 
LIB/INCLUDE values found through the registry.

-- 
Marc-Andre Lemburg
CEO eGenix.com Software GmbH
______________________________________________________________________
Consulting & Company:                           http://www.egenix.com/
Python Software:                        http://www.lemburg.com/python/



From Paul.Moore@atosorigin.com  Mon Jul 16 09:50:00 2001
From: Paul.Moore@atosorigin.com (Moore, Paul)
Date: Mon Jul 16 08:50:00 2001
Subject: [Distutils] Distutils enhancement - set variables from the co
 mmand  line
Message-ID: <714DFA46B9BBD0119CD000805FC1F53B01B5AEFA@ukrux002.rundc.uk.origin-it.com>

>From: M.-A. Lemburg [mailto:mal@lemburg.com]
> Paul Moore wrote:
>> My suggestion would be to allow the "global_opts" or "cmdX_opts" to
contain
>> arguments of the form key=value. These can be exposed to setup.py as a
>> dictionary, say distutils.args.
>> 
>> What do people think?
>
> Doesn't setup.cfg provide enough means for the user to customize the
> distutils behaviour ?

Not really. As far as I can see from the documentation, it allows the user
to set existing command line options. It doesn't allow the user to supply
arbitrary configuration information.

The example I hit this with was installing a module which depended on the
JPEG library. On Windows, there is no "standard" location where such a
library would be installed. It is not unlikely, however, that the user might
have built the library just to install this extension - so a reasonable
default might be ..\jpeg-6b. So I envision setup.py having something like:

    JPEG_LOCN = distutils.args.get('JPEG_LOCN', '../jpeg-6b')

The user can then either run

    python setup.py build
or
    python setup.py build JPEG_LOCN=C:\LocalLibs\JPEG

depending on his setup.

Paul.


From Paul.Moore@atosorigin.com  Mon Jul 16 10:03:01 2001
From: Paul.Moore@atosorigin.com (Moore, Paul)
Date: Mon Jul 16 09:03:01 2001
Subject: [Distutils] Why doesn't distutils respect the INCLUDE/LIB  en
 vironment variable (MSVC)?
Message-ID: <714DFA46B9BBD0119CD000805FC1F53B01B5AEFB@ukrux002.rundc.uk.origin-it.com>

From: M.-A. Lemburg [mailto:mal@lemburg.com]
> I don't know about the convention for looking up parameters
> on Windows: do env vars override settings in the registry
> or the other way around ?

I just checked. It's actually worse than I thought. The environment
variables are the *only* thing that affect the command-line tools. The
registry is purely for the IDE, I guess. So what distutils is doing, rather
than being unhelpful, is actually wrong...

It *is* possible to install Visual C++ in such a way that the environment
variables are not set by default, leaving the user to run a BAT file to set
them up before the command line tools are usable. It's possible that the
distutils approach is to cater for such users, by registering the
appropriate variables even if VCVARS32.BAT has not been run.

> Depending on what the standard procedure is on Windows, I'd
> suggest to either prepend or append the env var settings to the 
> LIB/INCLUDE values found through the registry.

Based on the above, I'd suggest not grubbing through the registry at all -
just leave things as the user has them. Or to handle the case where the user
hasn't set the environment variables, maybe check whether INCLUDE is set -
if not, either prompt the user (probably better, as VCVARS32.BAT definitely
does the right thing), or grub through the registry in that case only.

A bare minimum patch (which just leaves the vars if set, otherwise works as
at present) could be (UNTESTED):

--- msvccompiler.py.orig	Thu Apr 19 10:24:24 2001
+++ msvccompiler.py	Mon Jul 16 14:02:05 2001
@@ -155,8 +155,11 @@
 def set_path_env_var (name, version_number):
     """Set environment variable 'name' to an MSVC path type value obtained
        from 'get_msvc_paths()'.  This is equivalent to a SET command prior
-       to execution of spawned commands."""
+       to execution of spawned commands.  If the environment variable is
+       already set, leave it alone."""
 
+    if os.environ.has_key(name)
+        return
     p = get_msvc_paths (name, version_number)
     if p:
         os.environ[name] = string.join (p,';')

Paul.


From mal@lemburg.com  Tue Jul 17 13:41:01 2001
From: mal@lemburg.com (M.-A. Lemburg)
Date: Tue Jul 17 12:41:01 2001
Subject: [Distutils] Distutils enhancement - set variables from the command
 line
References: <714DFA46B9BBD0119CD000805FC1F53B01B5AEFA@ukrux002.rundc.uk.origin-it.com>
Message-ID: <3B54619D.F7B3F12F@lemburg.com>

"Moore, Paul" wrote:
> 
> >From: M.-A. Lemburg [mailto:mal@lemburg.com]
> > Paul Moore wrote:
> >> My suggestion would be to allow the "global_opts" or "cmdX_opts" to
> contain
> >> arguments of the form key=value. These can be exposed to setup.py as a
> >> dictionary, say distutils.args.
> >>
> >> What do people think?
> >
> > Doesn't setup.cfg provide enough means for the user to customize the
> > distutils behaviour ?
> 
> Not really. As far as I can see from the documentation, it allows the user
> to set existing command line options. It doesn't allow the user to supply
> arbitrary configuration information.

There's no such thing as "arbitrary configuration information" ;-)

Configuration parameters always have to be written down in some
setup.py file and making them additionally available as options is 
really easy with distutils.
 
> The example I hit this with was installing a module which depended on the
> JPEG library. On Windows, there is no "standard" location where such a
> library would be installed. It is not unlikely, however, that the user might
> have built the library just to install this extension - so a reasonable
> default might be ..\jpeg-6b. So I envision setup.py having something like:
> 
>     JPEG_LOCN = distutils.args.get('JPEG_LOCN', '../jpeg-6b')

Why not simply add an --jpeg=<location> option to the build command
by subclassing the standard one in distutils (I do that a lot in the
eGenix mx stuff and it works just fine -- distutils is wonderful
at this; I wish it would use that paradigm more often, e.g. for
compiler classes as well) ?
 
> The user can then either run
> 
>     python setup.py build
> or
>     python setup.py build JPEG_LOCN=C:\LocalLibs\JPEG
> 
> depending on his setup.

-- 
Marc-Andre Lemburg
CEO eGenix.com Software GmbH
______________________________________________________________________
Consulting & Company:                           http://www.egenix.com/
Python Software:                        http://www.lemburg.com/python/


From akuchlin@mems-exchange.org  Tue Jul 17 16:39:01 2001
From: akuchlin@mems-exchange.org (Andrew Kuchling)
Date: Tue Jul 17 15:39:01 2001
Subject: [Distutils] Re: Package DB: strawman PEP
In-Reply-To: <87bsmur2pc.fsf@cgsoftware.com>; from dan@cgsoftware.com on Mon, Jul 09, 2001 at 03:17:35AM -0400
References: <20010708234624.A30892@ute.cnri.reston.va.us> <87bsmur2pc.fsf@cgsoftware.com>
Message-ID: <20010717153755.C15369@ute.cnri.reston.va.us>

[Picking up the package-DB thread from last week]

On Mon, Jul 09, 2001 at 03:17:35AM -0400, Daniel Berlin wrote:
>This can easily be rebuilt in case of corruption, since *it* was
>generated initially by scanning the files (you just keep it up to date
>when you install packages, and if something gets out of whack,
>completely rebuild it).

The real package database implementation will very likely build a
cached version of the data using anydbm or some faster mechanism.  I
don't think the PEP needs to specify that, though if people disagree
it could certainly be added.  I 

>>         An initial line listing the sections in this file, separated
>>         by whitespace.  Currently this will always be 'PKG-INFO
>>         FILES'.  This is for future-proofing; if we add a new section,
>>         for example to list documentation files, then we'd add a DOCS
>>         section and list it in the contents.  Sections are always
>>         separated by blank lines.  XXX too simple?
  ...
>>     Each file's entry is a single tab-delimited line that contains the
>>     following fields: 

>Can we try to keep delimiters the same where possible (IE why use
>whitespace here, but tabs for file entries)?  

Fair enough; I was thinking the information for a single file is small
enough, and easy enough to get right initially, so it shouldn't need
extending later.  Perhaps RFC822-style should be reused again to list
files:

Name: /usr/local/lib/python2.1/site-packages/mymodule.py
Mode: 0644
Size: 565
Digest: 01abcdef...
Name: /usr/local/lib/python2.1/site-packages/mymodule2.py
Mode: 0644
Size: 1024
Digest: 02fedbca...

There should be blank lines to mark the end of each file's stanza, but
that breaks the idea of using blank lines to indicate the end of a
section.  Perhaps the 'Files' section should simply always come last,
and therefore safely break that convention.

>>owner/group will get you in trouble if the owner/group doesn't exist
>on the other system.

Good point.

>>         * XXX some sort of type indicator, to indicate whether this is
>>           a Python module, binary module, documentation file, config
>>           file?  Do we need this?
>Well, it would allow you to purge docs seperately from the rest of the
>package, or purge everything but the config files. I've used both
>options myself. The other option is to put docs in a seperate package.

Docs in a separate package is unlikely, so I suppose we need to use a
type indicator.  

--amk


From gustav@morpheus.demon.co.uk  Tue Jul 17 16:44:15 2001
From: gustav@morpheus.demon.co.uk (Paul Moore)
Date: Tue Jul 17 15:44:15 2001
Subject: [Distutils] Distutils enhancement - set variables from the command   line
In-Reply-To: <3B54619D.F7B3F12F@lemburg.com>
References: <714DFA46B9BBD0119CD000805FC1F53B01B5AEFA@ukrux002.rundc.uk.origin-it.com> <3B54619D.F7B3F12F@lemburg.com>
Message-ID: <v719lt8p2pjtkgu9oipgh00mo9mvtn6fnv@4ax.com>

On Tue, 17 Jul 2001 18:02:37 +0200, M.-A. Lemburg wrote:

>There's no such thing as "arbitrary configuration information" ;-)
>
>Configuration parameters always have to be written down in some
>setup.py file and making them additionally available as options is=20
>really easy with distutils.
[...]
>Why not simply add an --jpeg=3D<location> option to the build command
>by subclassing the standard one in distutils (I do that a lot in the
>eGenix mx stuff and it works just fine -- distutils is wonderful
>at this; I wish it would use that paradigm more often, e.g. for
>compiler classes as well) ?

... because I didn't know you could do that.

That's excellent - it simply never occurred to me that something like =
that would
be possible, let alone easy. I am still thinking in makefile terms (or at=
 best,
in Perl MakeMaker terms), where this sort of thing is annoyingly =
difficult, if
it's even possible.

It's this sort of flexibility that makes Python *so* nice to use. It's =
just a
pity that there isn't enough of this type of feature documented for =
distutils.

Thanks for pointing this out to me. I'll go and have a look at the mx =
setup
files, for further enlightenment...

Paul.


From slash@dotnetslash.net  Tue Jul 17 19:25:59 2001
From: slash@dotnetslash.net (Mark W. Alexander)
Date: Tue Jul 17 18:25:59 2001
Subject: [Distutils] Re: Package DB: strawman PEP
In-Reply-To: <20010717153755.C15369@ute.cnri.reston.va.us>
Message-ID: <Pine.LNX.4.21.0107171759180.3575-100000@llave.eproinet.com>

On Tue, 17 Jul 2001, Andrew Kuchling wrote:

> [Picking up the package-DB thread from last week]
> 
> On Mon, Jul 09, 2001 at 03:17:35AM -0400, Daniel Berlin wrote:
> >This can easily be rebuilt in case of corruption, since *it* was
> >generated initially by scanning the files (you just keep it up to date
> >when you install packages, and if something gets out of whack,
> >completely rebuild it).
> 
> The real package database implementation will very likely build a
> cached version of the data using anydbm or some faster mechanism.  I
> don't think the PEP needs to specify that, though if people disagree
> it could certainly be added.  I 

This is starting to bother me even more than it did at first.

If Distutils has a package database, and you use it to generate a
native binary package, will the generated package update the distutils
database, the native package manager's database, both, or neither?
There's a whole boatload of problems no matter which answer you pick.

The discussions so far have indicated to me that the primary problem
is that the Windows platform has no true "native" manager. Does it
make sense to provide this as part of Distutils for the sake of one
platform, or does it make more sense to standardize on a installer for
Windows that provides package management. Distutils bdist_win*
packages would then be handled through a consistent interface that
would register their contents properly. It could even go further, and
properly manage multiple Python installations on the same machine,
with different Distutils packages in each tree.

Maybe I'm out in left field, here, but what exactly is the problem
that this PEP is trying to solve? Every package manager I'm aware of
covers all the questions in the "Requirements" statement, with the
possible exception of "Where can I download a new version?" I always
manage to find a place to stick that info (VENDOR, HOTLINE, or some
such), so it _can_ be grafted into the PEP241 metadata usage for
binary packaging. This is exactly why I wrote bdist_packager (patch
#415226).  So that module authors could provide metadata in a single
unified manner which Distutils bdist commands can slice and dice
appropriately for each supported package manager.

Think about this, please. If you are going to continue a python
repository of this scale, are you going to discontinue support for
native binaries? It just doesn't make sense to do both.

mwa





From Paul.Moore@atosorigin.com  Wed Jul 18 10:59:28 2001
From: Paul.Moore@atosorigin.com (Moore, Paul)
Date: Wed Jul 18 09:59:28 2001
Subject: [Distutils] PEP 250: Summary of comments
Message-ID: <714DFA46B9BBD0119CD000805FC1F53B01B5AF15@UKRUX002.rundc.uk.origin-it.com>

Having waited a few days to let the dust settle, I believe that the
following is the current state of affairs:

1. The change to site.py, to include site-packages in sys.path, is in.
2. The change to distutils.sysconfig to change to site-packages, is in.
3. The Windows Installer still needs changes:
   a) site.py should change to export a "sys.extinstallpath" which points to
site-packages
   b) the Windows Installer should use this, rather than the registry

I see no great issue with 3a - it should be a pretty trivial change. Can
someone with access to the sources make it? I attach a suggested patch. Item
3b is the key point - it's pretty critical that the Windows Installer change
to use the new directory, otherwise, most of the work is a waste. I can't do
much about this, as I haven't even seen the source yet. Can someone do
something about this?

On point 3a, sys.extinstallpath should be set for all platforms, but I have
to admit that I don't know what to do for non-Windows platforms. The best I
can suggest is that we do something like

if os.sep == '/':
    sys.extinstallpath = os.path.join(sys.prefix, "lib", "python" +
sys.version[:3], "site-packages")
else:
    sys.extinstallpath = os.path.join(sys.prefix, "lib", "site-packages")

which matches the sys.path setting for Unix - but I couldn't really offer
this as a patch, as I don't understand the issues around site-packages vs
site-python on Unix. All I could say is that it's better than leaving
sys.extinstallpath unset on some platforms.

To summarise the summary:

1. The patch to site.py to expose sys.extinstallpath should be made, at
least for Windows.
2. The Windows Installer needs to be updated to use sys.extinstallpath for
Python 2.2 and greater.
3. If the Mac people want, the same can be done for Mac.
4. If the Unix people have a consensus, that should go in too (affects
site.py, bdist_rpm, at least).

As a side benefit, if this goes in, bdist_wininst will start working for
Pythons which don't use the registry (such as the PythonLabs ones).

Sadly, I note that I've just missed the 2.2a1 release. Is anyone likely to
be able to do anything about this prior to 2.2a2? (If someone sends me a
pointer to the wininst sources, I'll look into what's involved in a patch,
assuming no-one else has adequate time).

Paul.

PS As documentation of sys.extinstallpath, I'd suggest something like:

sys.extinstallpath: The directory into which Python extensions should be
installed. This is merely a recommendation - Python will pick up extensions
which are located anywhere along sys.path. However, extension installers
should use this directory by default. The distutils package (and installers
built with it) will use this directory (XXX - currently not trie for
bdist_rpm, I guess).

Patch for site.py (point 3a - Windows only, from Thomas Heller)

--- \Applications\Python\lib\site.py.orig    Tue Jun 26 10:07:06 2001
+++ \Applications\Python\lib\site.py   Wed Jul 18 14:43:54 2001
@@ -148,6 +148,9 @@
             if os.path.isdir(sitedir):
                 addsitedir(sitedir)

+if os.sep == '\\': # != '/' if you want to do all except Unix like this...
+    sys.extinstallpath = os.path.join(sys.prefix, "lib", "site-packages")
+
 # Define new built-ins 'quit' and 'exit'.
 # These are simply strings that display a hint on how to exit.
 if os.sep == ':':


From Paul.Moore@atosorigin.com  Wed Jul 18 11:23:45 2001
From: Paul.Moore@atosorigin.com (Moore, Paul)
Date: Wed Jul 18 10:23:45 2001
Subject: [Distutils] PEP 250: Summary of comments
Message-ID: <714DFA46B9BBD0119CD000805FC1F53B01B5AF16@UKRUX002.rundc.uk.origin-it.com>

From: Moore, Paul [mailto:Paul.Moore@atosorigin.com]
> Having waited a few days to let the dust settle, I believe that the
> following is the current state of affairs:
>
> 1. The change to site.py, to include site-packages in sys.path, is in.
> 2. The change to distutils.sysconfig to change to site-packages, is in.

Urk. I just downloaded 2.2a1, and the sysconfig.py change isn't in :-(

Attached are a couple of possible patches - one which just tweaks Windows
(os.name is 'nt' for Win9x???) and another which tries to slim down on the
platform-specific special casing, but which may have larger effects on
non-Windows platforms.

Can someone put one of these in?

Thanks,
Paul.

Trivial version of the change:

--- sysconfig.py.orig        Sat Jul 07 23:55:28 2001
+++ sysconfig.py   Wed Jul 18 15:13:45 2001
@@ -89,7 +89,7 @@
         if standard_lib:
             return os.path.join(PREFIX, "Lib")
         else:
-            return prefix
+            return os.path.join(libpython, "site-packages")

     elif os.name == "mac":
         if plat_specific:

Better version, which covers all platforms (but which removes a couple of
"OK, where DO site-specific modules go on the Mac?" errors, which may be
glossing over an issue...) is

--- sysconfig.py.orig	Sat Jul 07 23:55:28 2001
+++ sysconfig.py	Wed Jul 18 15:18:55 2001
@@ -80,35 +80,23 @@
     if os.name == "posix":
         libpython = os.path.join(prefix,
                                  "lib", "python" + sys.version[:3])
-        if standard_lib:
-            return libpython
-        else:
-            return os.path.join(libpython, "site-packages")
-
     elif os.name == "nt":
-        if standard_lib:
-            return os.path.join(PREFIX, "Lib")
-        else:
-            return prefix
-
+        libpython = os.path.join(PREFIX, "Lib")
     elif os.name == "mac":
         if plat_specific:
-            if standard_lib:
-                return os.path.join(EXEC_PREFIX, "Mac", "Plugins")
-            else:
-                raise DistutilsPlatformError, \
-                      "OK, where DO site-specific extensions go on the
Mac?"
+            libpython = os.path.join(EXEC_PREFIX, "Mac", "Plugins")
         else:
-            if standard_lib:
-                return os.path.join(PREFIX, "Lib")
-            else:
-                raise DistutilsPlatformError, \
-                      "OK, where DO site-specific modules go on the Mac?"
+            libpython = os.path.join(PREFIX, "Lib")
     else:
         raise DistutilsPlatformError, \
               ("I don't know where Python installs its library " +
                "on platform '%s'") % os.name
 
+    if standard_lib:
+        return libpython
+    else:
+        return os.path.join(libpython, "site-packages")
+
 # get_python_lib()
         


From fdrake@acm.org  Wed Jul 18 11:28:59 2001
From: fdrake@acm.org (Fred L. Drake, Jr.)
Date: Wed Jul 18 10:28:59 2001
Subject: [Distutils] Re: [Python-Dev] PEP 250: Summary of comments
In-Reply-To: <714DFA46B9BBD0119CD000805FC1F53B01B5AF15@UKRUX002.rundc.uk.origin-it.com>
References: <714DFA46B9BBD0119CD000805FC1F53B01B5AF15@UKRUX002.rundc.uk.origin-it.com>
Message-ID: <15189.40082.973330.760541@cj42289-a.reston1.va.home.com>

Moore, Paul writes:
 > On point 3a, sys.extinstallpath should be set for all platforms, but I have
 > to admit that I don't know what to do for non-Windows platforms. The best I
 > can suggest is that we do something like
 > 
 > if os.sep == '/':
 >     sys.extinstallpath = os.path.join(sys.prefix, "lib", "python" +
 > sys.version[:3], "site-packages")
 > else:
 >     sys.extinstallpath = os.path.join(sys.prefix, "lib", "site-packages")

  There's one aspect that doesn't appear to have been addressed for
Unix: there are two reasonable values for extinstallpath.  In
multi-architecture installations, where the Python portions of the
library are shared among architectures, there are two site-packages
directories:

	$prefix/lib/pythonX.Y/site-packages/

and

	$exec_prefix/lib/pythonX.Y/site-packages/

  When $prefix and $exec_prefix are the same, this isn't an issue, but
for this is a problem for multi-platform installations.


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at acm.org>
PythonLabs at Digital Creations



From guido@digicool.com  Wed Jul 18 11:33:06 2001
From: guido@digicool.com (Guido van Rossum)
Date: Wed Jul 18 10:33:06 2001
Subject: [Python-Dev] RE: [Distutils] PEP 250: Summary of comments
In-Reply-To: Your message of "Wed, 18 Jul 2001 15:21:03 BST."
 <714DFA46B9BBD0119CD000805FC1F53B01B5AF16@UKRUX002.rundc.uk.origin-it.com>
References: <714DFA46B9BBD0119CD000805FC1F53B01B5AF16@UKRUX002.rundc.uk.origin-it.com>
Message-ID: <200107181436.KAA28132@cj20424-a.reston1.va.home.com>

> Can someone put one of these in?

Don't count on me -- I haven't followed this discussion at all.  Sorry.

--Guido van Rossum (home page: http://www.python.org/~guido/)


From Paul.Moore@atosorigin.com  Wed Jul 18 11:42:06 2001
From: Paul.Moore@atosorigin.com (Moore, Paul)
Date: Wed Jul 18 10:42:06 2001
Subject: [Distutils] RE: [Python-Dev] PEP 250: Summary of comments
Message-ID: <714DFA46B9BBD0119CD000805FC1F53B01B5AF17@UKRUX002.rundc.uk.origin-it.com>

From: Fred L. Drake, Jr. [mailto:fdrake@acm.org]
> There's one aspect that doesn't appear to have been addressed for
> Unix: there are two reasonable values for extinstallpath.  In
> multi-architecture installations, where the Python portions of the
> library are shared among architectures, there are two site-packages
> directories:

I agree entirely. I have no knowledge of the issues on Unix, and hence I can
make no comment.

As far as I am concerned, I feel very strongly that this should go in for
Windows (where I believe that the current use of a "bare" sys.prefix is
wrong), but I have no view at all on other platforms. My PEP was originally
entitled "Using site-packages on Windows" - I am happy if the scope gets
extended, but don't rely on me to do it - and please don't let the key point
(for me) which is fixing Windows, get sidetracked by issues for Unix, where
(as far as I know) the current status quo is perfectly acceptable to the
majority of users.

So I'd vote to leave sys.extinstallpath undefined except on Windows, and
leave the other platforms for a new PEP.

Paul.


From mal@lemburg.com  Wed Jul 18 12:01:37 2001
From: mal@lemburg.com (M.-A. Lemburg)
Date: Wed Jul 18 11:01:37 2001
Subject: [Distutils] Re: [Python-Dev] PEP 250: Summary of comments
References: <714DFA46B9BBD0119CD000805FC1F53B01B5AF15@UKRUX002.rundc.uk.origin-it.com> <15189.40082.973330.760541@cj42289-a.reston1.va.home.com>
Message-ID: <3B55A499.42F55B5A@lemburg.com>

"Fred L. Drake, Jr." wrote:
> 
> Moore, Paul writes:
>  > On point 3a, sys.extinstallpath should be set for all platforms, but I have
>  > to admit that I don't know what to do for non-Windows platforms. The best I
>  > can suggest is that we do something like
>  >
>  > if os.sep == '/':
>  >     sys.extinstallpath = os.path.join(sys.prefix, "lib", "python" +
>  > sys.version[:3], "site-packages")
>  > else:
>  >     sys.extinstallpath = os.path.join(sys.prefix, "lib", "site-packages")
> 
>   There's one aspect that doesn't appear to have been addressed for
> Unix: there are two reasonable values for extinstallpath.  In
> multi-architecture installations, where the Python portions of the
> library are shared among architectures, there are two site-packages
> directories:
> 
>         $prefix/lib/pythonX.Y/site-packages/
> 
> and
> 
>         $exec_prefix/lib/pythonX.Y/site-packages/
> 
>   When $prefix and $exec_prefix are the same, this isn't an issue, but
> for this is a problem for multi-platform installations.

I don't think this is an issue since distutils already knows
that extension package live in .../site-package on Unix. 

The Windows install and unix_home are the only ones which copy
the files into non-standard dirs (Unix seems to be the only
target which supports multi-platform installs out-of-the-box):

[taken from distutils.commands.install]
"""
INSTALL_SCHEMES = {
    'unix_prefix': {
        'purelib': '$base/lib/python$py_version_short/site-packages',
        'platlib': '$platbase/lib/python$py_version_short/site-packages',
        'headers': '$base/include/python$py_version_short/$dist_name',
        'scripts': '$base/bin',
        'data'   : '$base',
        },
    'unix_home': {
        'purelib': '$base/lib/python',
        'platlib': '$base/lib/python',
        'headers': '$base/include/python/$dist_name',
        'scripts': '$base/bin',
        'data'   : '$base',
        },
    'nt': {
        'purelib': '$base',
        'platlib': '$base',
        'headers': '$base/Include/$dist_name',
        'scripts': '$base/Scripts',
        'data'   : '$base',
        },
    'mac': {
        'purelib': '$base/Lib/site-packages',
        'platlib': '$base/Lib/site-packages',
        'headers': '$base/Include/$dist_name',
        'scripts': '$base/Scripts',
        'data'   : '$base',
        }
    }
"""

Paul, note that your patches don't even touch install.py -- are 
your sure that the patch to sysconfig.py suffices to have distutils
install the extensions into site-packages on Windows ?

(I believe that install.py would have to be told about
sys.extinstallpath too and that it should fallback to the
defaults given in the install schemes if it is not set.)

-- 
Marc-Andre Lemburg
CEO eGenix.com Software GmbH
______________________________________________________________________
Consulting & Company:                           http://www.egenix.com/
Python Software:                        http://www.lemburg.com/python/


From fdrake@acm.org  Wed Jul 18 12:09:01 2001
From: fdrake@acm.org (Fred L. Drake, Jr.)
Date: Wed Jul 18 11:09:01 2001
Subject: [Distutils] Re: [Python-Dev] PEP 250: Summary of comments
In-Reply-To: <3B55A499.42F55B5A@lemburg.com>
References: <714DFA46B9BBD0119CD000805FC1F53B01B5AF15@UKRUX002.rundc.uk.origin-it.com>
 <15189.40082.973330.760541@cj42289-a.reston1.va.home.com>
 <3B55A499.42F55B5A@lemburg.com>
Message-ID: <15189.42456.461317.848018@cj42289-a.reston1.va.home.com>

M.-A. Lemburg writes:
 > I don't think this is an issue since distutils already knows
 > that extension package live in .../site-package on Unix. 

  Frankly, I'm not convinced that there's a need for extinstallpath.
Why not define INSTALL_SCHEMES like this:

if sys.version < "2.2":
    WINDOWS_SCHEME = {
        'purelib': '$base',
        'platlib': '$base',
        'headers': '$base/Include/$dist_name',
        'scripts': '$base/Scripts',
        'data'   : '$base',
        }
else:
    WINDOWS_SCHEME = {
        'purelib': '$base/Lib/site-packages',
        'platlib': '$base/Lib/site-packages',
        'headers': '$base/Include/$dist_name',
        'scripts': '$base/Scripts',
        'data'   : '$base',
        }

INSTALL_SCHEMES = {
    'nt': WINDOWS_SCHEME,
    ...
    }


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at acm.org>
PythonLabs at Digital Creations



From Paul.Moore@atosorigin.com  Wed Jul 18 12:16:00 2001
From: Paul.Moore@atosorigin.com (Moore, Paul)
Date: Wed Jul 18 11:16:00 2001
Subject: [Distutils] Re: [Python-Dev] PEP 250: Summary of comments
Message-ID: <714DFA46B9BBD0119CD000805FC1F53B01B5AF1A@UKRUX002.rundc.uk.origin-it.com>

From: M.-A. Lemburg [mailto:mal@lemburg.com]
> Paul, note that your patches don't even touch install.py -- are 
> your sure that the patch to sysconfig.py suffices to have distutils
> install the extensions into site-packages on Windows ?

AAARGH! I guess you are right - I missed this somehow. I thought I'd
checked, but the grep I did must have missed this one.

I will attempt to sort out a patch which actually works. However, I should
point out:

1. I've never looked at the internals code for distutils in any detail, so I
can't be sure that what I'm doing is complete. Reviewers would be gratefully
received (Marc, both your comments and Thomas' have been very helpful in
this regard so far).

2. I can't do anything about bdist_wininst. I hope Thomas is listening, and
can offer some help here :-)

3. I'll have to do a patch against Python 2.1. I don't have 2.2a1 installed
yet.

4. I don't have a particularly large testbed of applications to check all
this - I'm working on my main machine, and I'll be in trouble if I break the
setup by indiscriminate hacking...

5. I'm totally reliant on someone else feeding my changes into the current
CVS. This is frustrating, to say the least. (I understand that people are
very busy - but I've already sent in one complete patch, along with the
final PEP, which didn't get applied - instead, the site.py part was
reimplemented, and the sysconfig.py part missed completely :-()

Anyway, I'll report back ASAP...

Paul.


From thomas.heller@ion-tof.com  Wed Jul 18 12:27:00 2001
From: thomas.heller@ion-tof.com (Thomas Heller)
Date: Wed Jul 18 11:27:00 2001
Subject: [Distutils] Re: [Python-Dev] PEP 250: Summary of comments
References: <714DFA46B9BBD0119CD000805FC1F53B01B5AF1A@UKRUX002.rundc.uk.origin-it.com>
Message-ID: <008501c10f9e$00ec2550$e000a8c0@thomasnotebook>

From: "Moore, Paul" <Paul.Moore@atosorigin.com>
> 
> I will attempt to sort out a patch which actually works. However, I should
> point out:
> 
> 1. I've never looked at the internals code for distutils in any detail, so I
> can't be sure that what I'm doing is complete. Reviewers would be gratefully
> received (Marc, both your comments and Thomas' have been very helpful in
> this regard so far).
> 
> 2. I can't do anything about bdist_wininst. I hope Thomas is listening, and
> can offer some help here :-)
I am, and I bdist_wininst *will* be ready when the rest is complete.

I already have a version which retrieves sys.extinstallpath at run time.

> 
> 3. I'll have to do a patch against Python 2.1. I don't have 2.2a1 installed
> yet.
> 
> 4. I don't have a particularly large testbed of applications to check all
> this - I'm working on my main machine, and I'll be in trouble if I break the
> setup by indiscriminate hacking...
> 
> 5. I'm totally reliant on someone else feeding my changes into the current
> CVS. This is frustrating, to say the least. (I understand that people are
> very busy - but I've already sent in one complete patch, along with the
> final PEP, which didn't get applied - instead, the site.py part was
> reimplemented, and the sysconfig.py part missed completely :-()

I already posted the link to access Python's cvs repository via http.
(Can easily be found starting at http://python.sourceforge.net/).
This is implemented via Greg Stein's ViewCVS - check it out, it is
very powerful!

Thomas



From Paul.Moore@atosorigin.com  Wed Jul 18 12:53:04 2001
From: Paul.Moore@atosorigin.com (Moore, Paul)
Date: Wed Jul 18 11:53:04 2001
Subject: [Distutils] Re: [Python-Dev] PEP 250: Summary of comments
Message-ID: <714DFA46B9BBD0119CD000805FC1F53B01B5AF1B@UKRUX002.rundc.uk.origin-it.com>

From: M.-A. Lemburg [mailto:mal@lemburg.com]
> (I believe that install.py would have to be told about
> sys.extinstallpath too and that it should fallback to the
> defaults given in the install schemes if it is not set.)

Hmm, browsing this a bit more, I'm getting further confused. The cause of
this is the INSTALL_SCHEMES stuff, which has a purelib/platlib distinction,
which is only used on unix_prefix (all other cases use the same value for
both of these). I can't see how sys.extinstallpath relates - I could use it
as default for both purelib and platlib, but that somewhat defeats the point
of having the two. Does this imply that sys.extinstallpath should be split
into two parts (pure & plat)? I can't comment, as this is a Unix-only thing.

This is getting silly. I feel that the correct approach is to go back to my
original stance, of *only* changing Windows behaviour - leave the Unix and
Mac camps as they are. With that in mind, sys.extinstallpath seems like an
overgeneralisation, and the attached patch does everything bar handle
bdist_wininst. The Windows Installer should then do the same thing - load
Python, and generate os.path.join(sys.prefix, "lib", "site-packages") as the
destination directory. OK, so the same thing is hard-coded in four places,
but this whole area is rife with duplicated code, and fixing that issue is
way outside the scope of PEP 250.

For the limited purpose of making site-packages appear in sys.path, and
making python setup.py install install to site-packages, the attached patch
works. I've only tested it on a simple Python module, but that's all I have
to hand. I can try some C modules tonight when I get home, but I see no
reason why they wouldn't work as well. The patch is pretty much trivial,
which (IMHO) is very much in its favour as Python 2.2a1 is already out...

Unless someone comes up with a *very strong* argument as to why I should be
going further than this, I would like to request that this goes into Python
as it stands. If someone can supply the source of the bdist_wininst
installer, I will make a corresponding change to that.

I will NOT make any changes which affect Unix, or Mac platforms. I don't
know the issues. If someone wants to supply a patch which does this, I'll be
happy to see it go in, and I am quite comfortable with it going under the
banner of PEP 250, but I will not get involved in the issues - I simply am
not qualified to comment.

Paul.

------------------------------------------------------

diff -u site.py.orig site.py
--- site.py.orig	Tue Jun 26 10:07:06 2001
+++ site.py	Wed Jul 18 16:33:37 2001
@@ -143,7 +143,7 @@
         elif os.sep == ':':
             sitedirs = [makepath(prefix, "lib", "site-packages")]
         else:
-            sitedirs = [prefix]
+            sitedirs = [prefix, makepath(prefix, "lib", "site-packages")]
         for sitedir in sitedirs:
             if os.path.isdir(sitedir):
                 addsitedir(sitedir)
diff -u distutils\sysconfig.py.orig distutils\sysconfig.py
--- distutils\sysconfig.py.orig	Thu Apr 19 10:24:24 2001
+++ distutils\sysconfig.py	Wed Jul 18 16:20:20 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
 
diff -u distutils\command\install.py.orig distutils\command\install.py
--- distutils\command\install.py.orig	Thu Apr 19 10:24:24 2001
+++ distutils\command\install.py	Wed Jul 18 16:29:29 2001
@@ -31,8 +31,8 @@
         'data'   : '$base',
         },
     'nt': {
-        'purelib': '$base',
-        'platlib': '$base',
+        'purelib': '$base/Lib/site-packages',
+        'platlib': '$base/Lib/site-packages',
         'headers': '$base/Include/$dist_name',
         'scripts': '$base/Scripts',
         'data'   : '$base',


From Paul.Moore@atosorigin.com  Wed Jul 18 13:00:05 2001
From: Paul.Moore@atosorigin.com (Moore, Paul)
Date: Wed Jul 18 12:00:05 2001
Subject: [Distutils] Re: [Python-Dev] PEP 250: Summary of comments
Message-ID: <714DFA46B9BBD0119CD000805FC1F53B01B5AF1D@UKRUX002.rundc.uk.origin-it.com>

From: Thomas Heller [mailto:thomas.heller@ion-tof.com]
>> 2. I can't do anything about bdist_wininst. I hope Thomas is listening,
and
>> can offer some help here :-)
> I am, and I bdist_wininst *will* be ready when the rest is complete.
>
> I already have a version which retrieves sys.extinstallpath at run time.

Great! Thanks for that. In recent messages, I've reached the point where I
can no longer see much use for sys.extinstallpath, unless the scope is
extended to Unix and Mac. In the absence of a suitable Unix/Mac expert,
that's not likely to happen...

Would you be willing to change to os.path.join(sys.prefix, "lib",
"site-packages") (as this is windows-specific, just sys.prefix +
"\\lib\\site-packages" would be fine)? Alternatively, I could expose
sys.extinstallpath from site.py solely for NT - I don't mind either way.

> I already posted the link to access Python's cvs repository via http.
> (Can easily be found starting at http://python.sourceforge.net/).
> This is implemented via Greg Stein's ViewCVS - check it out, it is
> very powerful!

I *thought* you had, but I couldn't find the message. Sorry - I'll have a
look later on.

Sorry - must rush now - hope this mail makes sense...
Paul.


From thomas.heller@ion-tof.com  Wed Jul 18 14:51:00 2001
From: thomas.heller@ion-tof.com (Thomas Heller)
Date: Wed Jul 18 13:51:00 2001
Subject: [Distutils] Re: [Python-Dev] PEP 250: Summary of comments
References: <714DFA46B9BBD0119CD000805FC1F53B01B5AF1B@UKRUX002.rundc.uk.origin-it.com>
Message-ID: <029101c10fb2$23257fe0$e000a8c0@thomasnotebook>

From: "Moore, Paul" <Paul.Moore@atosorigin.com>
> This is getting silly. I feel that the correct approach is to go back to my
> original stance, of *only* changing Windows behaviour - leave the Unix and
> Mac camps as they are.

This seems the way to go.

>  With that in mind, sys.extinstallpath seems like an
> overgeneralisation, and the attached patch does everything bar handle
> bdist_wininst.
There is one problem in the diffs below for distutils\sysconfig:
Your patch changes the result of get_python_lib() for standard_lib,
while it should change the directory for site-specific modules.
Correct (IMO) would be (maybe you created this in hurry):

    elif os.name == "nt":
        if standard_lib:
            return os.path.join(PREFIX, "Lib")
        else:
            return os.path.join(prefix, "Lib", "site-packages")


>  The Windows Installer should then do the same thing - load
> Python, and generate os.path.join(sys.prefix, "lib", "site-packages") as the
> destination directory.
No, it should load Python, and use the result of
distutils.sysconfig.get_python_lib() as theinstallation directory.
If this fails, revert to the previous behaviour.

This way would ensure the desired behaviour,
without a need to introduce sys.extinstallpath.

Maybe the PEP should eventually be updated if everyone agrees on this?

Thomas



From mal@lemburg.com  Wed Jul 18 16:24:05 2001
From: mal@lemburg.com (M.-A. Lemburg)
Date: Wed Jul 18 15:24:05 2001
Subject: [Distutils] Re: [Python-Dev] PEP 250: Summary of comments
References: <714DFA46B9BBD0119CD000805FC1F53B01B5AF15@UKRUX002.rundc.uk.origin-it.com>
 <15189.40082.973330.760541@cj42289-a.reston1.va.home.com>
 <3B55A499.42F55B5A@lemburg.com> <15189.42456.461317.848018@cj42289-a.reston1.va.home.com>
Message-ID: <3B55E251.7BEE00F0@lemburg.com>


"Fred L. Drake, Jr." wrote:
> 
> M.-A. Lemburg writes:
>  > I don't think this is an issue since distutils already knows
>  > that extension package live in .../site-package on Unix.
> 
>   Frankly, I'm not convinced that there's a need for extinstallpath.

Uhm... that's what I implied (or at least tried to imply) with 
my reply ;-)

> Why not define INSTALL_SCHEMES like this:
> 
> if sys.version < "2.2":
>     WINDOWS_SCHEME = {
>         'purelib': '$base',
>         'platlib': '$base',
>         'headers': '$base/Include/$dist_name',
>         'scripts': '$base/Scripts',
>         'data'   : '$base',
>         }
> else:
>     WINDOWS_SCHEME = {
>         'purelib': '$base/Lib/site-packages',
>         'platlib': '$base/Lib/site-packages',
>         'headers': '$base/Include/$dist_name',
>         'scripts': '$base/Scripts',
>         'data'   : '$base',
>         }
> 
> INSTALL_SCHEMES = {
>     'nt': WINDOWS_SCHEME,
>     ...
>     }
> 
>   -Fred
> 
> --
> Fred L. Drake, Jr.  <fdrake at acm.org>
> PythonLabs at Digital Creations
> 
> _______________________________________________
> Distutils-SIG maillist  -  Distutils-SIG@python.org
> http://mail.python.org/mailman/listinfo/distutils-sig

-- 
Marc-Andre Lemburg
CEO eGenix.com Software GmbH
______________________________________________________________________
Consulting & Company:                           http://www.egenix.com/
Python Software:                        http://www.lemburg.com/python/


From gustav@morpheus.demon.co.uk  Wed Jul 18 18:05:17 2001
From: gustav@morpheus.demon.co.uk (Paul Moore)
Date: Wed Jul 18 17:05:17 2001
Subject: [Distutils] Re: [Python-Dev] PEP 250: Summary of comments
In-Reply-To: <029101c10fb2$23257fe0$e000a8c0@thomasnotebook>
References: <714DFA46B9BBD0119CD000805FC1F53B01B5AF1B@UKRUX002.rundc.uk.origin-it.com> <029101c10fb2$23257fe0$e000a8c0@thomasnotebook>
Message-ID: <37ubltssig5rm9r6tkc5t235949v057shl@4ax.com>

On Wed, 18 Jul 2001 19:50:30 +0200, "Thomas Heller" =
<thomas.heller@ion-tof.com>
wrote:

>There is one problem in the diffs below for distutils\sysconfig:
>Your patch changes the result of get_python_lib() for standard_lib,
>while it should change the directory for site-specific modules.
>Correct (IMO) would be (maybe you created this in hurry):
>
>    elif os.name =3D=3D "nt":
>        if standard_lib:
>            return os.path.join(PREFIX, "Lib")
>        else:
>            return os.path.join(prefix, "Lib", "site-packages")

You're right. I did create this in a hurry, and I switched the logic. =
Thanks for
catching it. Unfortunately, I'm not sure where or how this code gets =
exercised,
so I didn't have an obvious way of testing this.

>No, it should load Python, and use the result of
>distutils.sysconfig.get_python_lib() as the installation directory.
>If this fails, revert to the previous behaviour.

That's a much better idea.

>This way would ensure the desired behaviour,
>without a need to introduce sys.extinstallpath.

Yes, I no longer see a use for sys.extinstallpath.

>Maybe the PEP should eventually be updated if everyone agrees on this?

I will certainly do so. As I understand it, the final version of the PEP =
should
serve as documentation for what actually gets implemented.

Thanks,
Paul.


From sophiec@scripps.edu  Wed Jul 18 20:20:01 2001
From: sophiec@scripps.edu (Sophie Coon)
Date: Wed Jul 18 19:20:01 2001
Subject: [Distutils] Distutils question
Message-ID: <3B5618DC.DB82ADDE@scripps.edu>

I want to distribute the library wrapped (gle) for Python for different
platform. We already have the .py and glecmodule.so for the different
platform can I use the following setup.py and MANIFEST.in and then do a
python2.0 setup.py sdist instead of listing the c extensions and c files
to build the libraries 

gle/
   setup.py:
	#!/usr/bin/env python2.0

	from distutils.core import setup, Extension
	import os, sys, string

	setup( name = "gle",
       	       version = "3.0",
               description = "GLE Tubing and Extrusion Library",
               author = "Linas Vepstas",
               author_email = "linas@linas.org",
               url = "http://www.linas.org/gle/",
               packages = ['']
       
             )
   MANIFEST.in
	include glecmodule.so 


Any information or suggestions will be great !

Thanks Sophie
	
-- 
############################################################
Sophie COON	              The Scripps Research Institute
Research Programmer III       Molecular Graphics Laboratory
			      10550 North Torrey Pines Road
Phone: (858) 784-9556                    La Jolla, CA 92037 
Fax  : (858) 784-2860
############################################################


From gustav@morpheus.demon.co.uk  Sat Jul 21 13:18:01 2001
From: gustav@morpheus.demon.co.uk (Paul Moore)
Date: Sat Jul 21 12:18:01 2001
Subject: [Distutils] The build_ext command has -I and -L options, why don't others???
Message-ID: <j77jltoibrfqnflnrjosg7lsu0qntm6rap@4ax.com>

I think this may be a fundamental flaw in the way distutils works... (By =
that, I
mean that it's something that "obviously" should work, but it's going to =
be
massively hard to implement that way :-() Let me know what you think.

I'm still hacking on my PIL setup.py file. My latest thought was that, =
given
that PIL needs the ZLib, JPEG and TCL libraries, and given that I don't =
have a
"standard" location to look in for them, what command line options might =
help.

And sure enough, I found the -I and -L options for the build_ext command.

Great! That's just what I want. Obviously (!), I'm using the "build" =
command,
but that executed build_ext behind the scenes for my extensions, so I'll =
just
pass -I and -L, and let build pass them on to build_ext as needed.

Oh, no... The build command complains that the -I and -L options are =
invalid.
Grr. I guess this means that I either have to run build_ext first, by =
hand, and
then run build (this works - well, it would if the build_clib command had=
 an -I
option, but that's a separate issue...), or I have to write a custom =
build
command which accepts -I and -L and passes them onto build_ext.

Surely, commands (like build and install) which run other commands should=
 take
*all* of the options allowed by any of their sub-commands, and pass them =
onto
those sub-commands. As I say, this seems obvious to me, but (having =
looked
briefly at the internals) annoyingly hard to do, in practice.

As I say, any thoughts?
Paul.

PS I think this pretty much kills any hope of writing a setup.py which =
usefully
implements command line argument extensions. You'd have to write custom =
commands
for every command, from the lowest one which needs the extra option, all =
the way
up the tree (install must be customised to take the same options as the =
custom
build, which must be customised to take the same options as the custom
build_ext, ...)


From gustav@morpheus.demon.co.uk  Sat Jul 21 13:18:03 2001
From: gustav@morpheus.demon.co.uk (Paul Moore)
Date: Sat Jul 21 12:18:03 2001
Subject: [Distutils] Distutils changes for PEP 250
Message-ID: <g58jltk8dq6umbk46r4crkq51rvbj8l7vb@4ax.com>

I think there's now been enough time to ensure that no further issues are=
 going
to come out. I therefore enclose a patch, which should, I believe, =
capture all
the issues.

Note:

1. It is against the CVS version of distutils, as on 21/07/2001. (I found=
 a way
of getting CVS to work for me. Yay!) There are no changes needed to core =
Python,
as the site.py change needed is in 2.2a1.

2. It covers Fred's issue of backward compatibility, by testing for =
sys.version
being 2.2 or greater - otherwise the old behaviour is retained.

3. It does nothing for platforms other than Windows. I'll leave the =
Unix/Mac
experts to decide if they want changes on their platforms.

4. I've tested it (relatively) minimally. It does install into =
site-packages
with the 'install' command. (And as expected, it doesn't on Python 2.1 - =
until
you remember to change the '2.2' to '2.1' in the code so that you can =
test it
:-))

All that this needs is for someone to approve and apply this patch. =
Thomas?
Would you be willing, given that you have made the necessary changes to =
the
Windows Installer to match this?

Thanks to all for the feedback. I've learned a lot, about distutils and =
the PEP
process. I don't think I'll be so free with my "why doesn't Python do =
XXX"
comments in future... (Maybe :-))

I'll go off and update the PEP now, to reflect what is (hopefully) the =
final
resolution.

Paul.

diff -u sysconfig.py.orig sysconfig.py
--- sysconfig.py.orig	Wed Jul 18 19:39:56 2001
+++ sysconfig.py	Sat Jul 21 16:38:36 2001
@@ -93,7 +93,10 @@
         if standard_lib:
             return os.path.join(PREFIX, "Lib")
         else:
-            return prefix
+            if sys.version < "2.2":
+                return prefix
+            else:
+                return os.path.join(PREFIX, "Lib", "site-packages")
=20
     elif os.name =3D=3D "mac":
         if plat_specific:
diff -u command\install.py.orig command\install.py
--- command\install.py.orig	Tue Jan 16 16:16:03 2001
+++ command\install.py	Sat Jul 21 16:41:15 2001
@@ -15,6 +15,23 @@
 from distutils.errors import DistutilsOptionError
 from glob import glob
=20
+if sys.version < "2.2":
+    WINDOWS_SCHEME =3D {
+        'purelib': '$base',
+        'platlib': '$base',
+        'headers': '$base/Include/$dist_name',
+        'scripts': '$base/Scripts',
+        'data'   : '$base',
+    }
+else:
+    WINDOWS_SCHEME =3D {
+        'purelib': '$base/Lib/site-packages',
+        'platlib': '$base/Lib/site-packages',
+        'headers': '$base/Include/$dist_name',
+        'scripts': '$base/Scripts',
+        'data'   : '$base',
+    }
+
 INSTALL_SCHEMES =3D {
     'unix_prefix': {
         'purelib': '$base/lib/python$py_version_short/site-packages',
@@ -30,13 +47,7 @@
         'scripts': '$base/bin',
         'data'   : '$base',
         },
-    'nt': {
-        'purelib': '$base',
-        'platlib': '$base',
-        'headers': '$base/Include/$dist_name',
-        'scripts': '$base/Scripts',
-        'data'   : '$base',
-        },
+    'nt': WINDOWS_SCHEME,
     'mac': {
         'purelib': '$base/Lib/site-packages',
         'platlib': '$base/Lib/site-packages',



From mal@lemburg.com  Sat Jul 21 16:12:00 2001
From: mal@lemburg.com (M.-A. Lemburg)
Date: Sat Jul 21 15:12:00 2001
Subject: [Distutils] The build_ext command has -I and -L options, why don't
 others???
References: <j77jltoibrfqnflnrjosg7lsu0qntm6rap@4ax.com>
Message-ID: <3B59D42C.A1163F4D@lemburg.com>

Paul Moore wrote:
> 
> I think this may be a fundamental flaw in the way distutils works... (By that, I
> mean that it's something that "obviously" should work, but it's going to be
> massively hard to implement that way :-() Let me know what you think.
> 
> I'm still hacking on my PIL setup.py file. My latest thought was that, given
> that PIL needs the ZLib, JPEG and TCL libraries, and given that I don't have a
> "standard" location to look in for them, what command line options might help.
> 
> And sure enough, I found the -I and -L options for the build_ext command.
> 
> Great! That's just what I want. Obviously (!), I'm using the "build" command,
> but that executed build_ext behind the scenes for my extensions, so I'll just
> pass -I and -L, and let build pass them on to build_ext as needed.
> 
> Oh, no... The build command complains that the -I and -L options are invalid.
> Grr. I guess this means that I either have to run build_ext first, by hand, and
> then run build (this works - well, it would if the build_clib command had an -I
> option, but that's a separate issue...), or I have to write a custom build
> command which accepts -I and -L and passes them onto build_ext.
> 
> Surely, commands (like build and install) which run other commands should take
> *all* of the options allowed by any of their sub-commands, and pass them onto
> those sub-commands. As I say, this seems obvious to me, but (having looked
> briefly at the internals) annoyingly hard to do, in practice.

python build_ext -I ... -L ... build

should do the trick.
 
> PS I think this pretty much kills any hope of writing a setup.py which usefully
> implements command line argument extensions. You'd have to write custom commands
> for every command, from the lowest one which needs the extra option, all the way
> up the tree (install must be customised to take the same options as the custom
> build, which must be customised to take the same options as the custom
> build_ext, ...)

AFAIK, all commands inherit command line option from the Distribution
class, so by subclassing you should be able to provide those extra
options to all subcommands. Could be wrong though... the option passing
in distutils is something of a mess.

-- 
Marc-Andre Lemburg
CEO eGenix.com Software GmbH
______________________________________________________________________
Consulting & Company:                           http://www.egenix.com/
Python Software:                        http://www.lemburg.com/python/


From gustav@morpheus.demon.co.uk  Sun Jul 22 18:07:20 2001
From: gustav@morpheus.demon.co.uk (Paul Moore)
Date: Sun Jul 22 17:07:20 2001
Subject: [Distutils] The build_ext command has -I and -L options, why don't  others???
In-Reply-To: <3B59D42C.A1163F4D@lemburg.com>
References: <j77jltoibrfqnflnrjosg7lsu0qntm6rap@4ax.com> <3B59D42C.A1163F4D@lemburg.com>
Message-ID: <l3gmltg396rlr0bva58qi96db6m90kr2u0@4ax.com>

On Sat, 21 Jul 2001 21:12:44 +0200, "M.-A. Lemburg" <mal@lemburg.com> =
wrote:

>python build_ext -I ... -L ... build
>
>should do the trick.

That's a bit messy, though - and not particularly intuitive.

>AFAIK, all commands inherit command line option from the Distribution
>class, so by subclassing you should be able to provide those extra
>options to all subcommands. Could be wrong though... the option passing
>in distutils is something of a mess.

I'll look into this - but I agree, the area is complex and non-trivial to
understand.

If I can get a simple example working, I'll write it up for the =
documentation. I
already have a nice simple "How to add a custom command" sample.

Paul.


From mal@lemburg.com  Mon Jul 23 05:07:01 2001
From: mal@lemburg.com (M.-A. Lemburg)
Date: Mon Jul 23 04:07:01 2001
Subject: [Distutils] The build_ext command has -I and -L options, why don't
 others???
References: <j77jltoibrfqnflnrjosg7lsu0qntm6rap@4ax.com> <3B59D42C.A1163F4D@lemburg.com> <l3gmltg396rlr0bva58qi96db6m90kr2u0@4ax.com>
Message-ID: <3B5BD58C.96008AB1@lemburg.com>

Paul Moore wrote:
> 
> On Sat, 21 Jul 2001 21:12:44 +0200, "M.-A. Lemburg" <mal@lemburg.com> wrote:
> 
> >python build_ext -I ... -L ... build
> >
> >should do the trick.
> 
> That's a bit messy, though - and not particularly intuitive.

Agreed, but it works ;-) (and you can also have your users edit
the setup.cfg file section for build_ext, so they won't really
notice)
 
> >AFAIK, all commands inherit command line option from the Distribution
> >class, so by subclassing you should be able to provide those extra
> >options to all subcommands. Could be wrong though... the option passing
> >in distutils is something of a mess.
> 
> I'll look into this - but I agree, the area is complex and non-trivial to
> understand.
> 
> If I can get a simple example working, I'll write it up for the documentation. I
> already have a nice simple "How to add a custom command" sample.

That'd be great !

-- 
Marc-Andre Lemburg
CEO eGenix.com Software GmbH
______________________________________________________________________
Consulting & Company:                           http://www.egenix.com/
Python Software:                        http://www.lemburg.com/python/



From gernot@tpg.com.au  Mon Jul 23 07:14:01 2001
From: gernot@tpg.com.au (Gernot Jander)
Date: Mon Jul 23 06:14:01 2001
Subject: [Distutils] directory for applications
Message-ID: <Pine.LNX.4.33.0107231108120.1524-100000@laptop.nihonsoft>

Is there any known "standard" directory location for complete applications
written in Python?

I think a typical internationalized application contains at least
four different file types:
1. an executable (Python-)script
2. one or more (Python-)modules (specific for this application)
3. one or more subdirectories containing xxx.mo files for gettext
4. a xxx.rc file for gtk-styles

Splitting this up in /usr/local/bin, /usr/python/site-packages and
/usr/local/share makes it hard to de-install the application. Furthermore
I think that application-specific modules should not go to site-packages,
since this is the place for global packages/modules and not for modules
that are only meaningfull in the context of one application.

Therefore I decided to have one /usr/local/python/xxx directory for each
of my applications and install all files there (besides the scripts).
But this solution implies to have these directories in the $PYTHONPATH
and makes the distribution not portable to other OS.

Are there any intentions to improve the support of applications in
distutils?

Asks
Gernot



From pehr@eink.com  Mon Jul 23 11:21:03 2001
From: pehr@eink.com (Pehr Anderson)
Date: Mon Jul 23 10:21:03 2001
Subject: [Distutils] directory for applications
In-Reply-To: <Pine.LNX.4.33.0107231108120.1524-100000@laptop.nihonsoft>; from gernot@tpg.com.au on Mon, Jul 23, 2001 at 11:40:44AM +0200
References: <Pine.LNX.4.33.0107231108120.1524-100000@laptop.nihonsoft>
Message-ID: <20010723101813.D11059@eink.com>

Dear Gernot,

For my applications installed with distutils,
I look at the sys.argv[0] argument for the path
in which my main python file resides. Then I append
a relative path to sys.path before I attempt to 
import my application modules.

This seems like a very reasonable way to do it.
I install the whole directory tree for my app
in /usr/local/appname or /usr/local/share/appname
and put a launch script in /usr/local/bin


	-pehr


On Mon, Jul 23, 2001 at 11:40:44AM +0200, Gernot Jander wrote:
> 
> Is there any known "standard" directory location for complete applications
> written in Python?
> 
> I think a typical internationalized application contains at least
> four different file types:
> 1. an executable (Python-)script
> 2. one or more (Python-)modules (specific for this application)
> 3. one or more subdirectories containing xxx.mo files for gettext
> 4. a xxx.rc file for gtk-styles
> 
> Splitting this up in /usr/local/bin, /usr/python/site-packages and
> /usr/local/share makes it hard to de-install the application. Furthermore
> I think that application-specific modules should not go to site-packages,
> since this is the place for global packages/modules and not for modules
> that are only meaningfull in the context of one application.
> 
> Therefore I decided to have one /usr/local/python/xxx directory for each
> of my applications and install all files there (besides the scripts).
> But this solution implies to have these directories in the $PYTHONPATH
> and makes the distribution not portable to other OS.
> 
> Are there any intentions to improve the support of applications in
> distutils?
> 
> Asks
> Gernot
> 
> 
> _______________________________________________
> Distutils-SIG maillist  -  Distutils-SIG@python.org
> http://mail.python.org/mailman/listinfo/distutils-sig

-- 
Pehr Anderson, E Ink Corporation, 617-499-6019, http://eink.com


From Juergen Hermann" <jhe@webde-ag.de  Tue Jul 24 09:55:01 2001
From: Juergen Hermann" <jhe@webde-ag.de (Juergen Hermann)
Date: Tue Jul 24 08:55:01 2001
Subject: [Distutils] extra_objects and dependencies
Message-ID: <m15P1hF-007oJYC@smtp.web.de>

Hi!

We have the problem that if you list additional objects as 
extra_objects in an Extension object, the linker is NOT called when one =

of these object files changes. Does that count as a bug?



Ciao, J=FCrgen

--
J=FCrgen Hermann, Developer (jhe@webde-ag.de)
WEB.DE AG, http://webde-ag.de/




From R.Liebscher@gmx.de  Tue Jul 24 10:25:01 2001
From: R.Liebscher@gmx.de (Rene Liebscher)
Date: Tue Jul 24 09:25:01 2001
Subject: [Distutils] extra_objects and dependencies
References: <m15P1hF-007oJYC@smtp.web.de>
Message-ID: <3B5D769D.88F3033E@gmx.de>

Juergen Hermann wrote:
> 
> Hi!
> 
> We have the problem that if you list additional objects as
> extra_objects in an Extension object, the linker is NOT called when one
> of these object files changes. Does that count as a bug?

Changing line 396 in distutils/commands/build_ext.py from

if not (self.force or newer_group(sources, ext_filename, 'newer')):

to 

if not (self.force or newer_group(sources + ext.extra_objects,
ext_filename, 'newer')):

might help. (But I have not tested it for myself.)
Default value of ext.extra_objects is [] so it
should not influence any other cases.


If this works someone who has write access to CVS might add it.



Kind regards
Rene Liebscher


From Kristen_Blanco@prenhall.com  Tue Jul 24 10:40:02 2001
From: Kristen_Blanco@prenhall.com (Kristen_Blanco@prenhall.com)
Date: Tue Jul 24 09:40:02 2001
Subject: [Distutils] Seeking technical reviewers for Python
Message-ID: <"/GUID:QFcigeTSA1RGZOABgCI2PYQ*/G=Kristen/S=Blanco/OU=exchange/O=pearsontc/PRMD=pearson/ADMD=telemail/C=us/"@MHS>

 am writing from Prentice Hall publishing and I am seeking reviewers for an upcoming publication. We are one of the
largest college textbook publishers in the US.

We are publishing a book entitled "Python How to Program" by
Harvey and Paul Deitel.  They are premier programming language authors, with the
best-selling C++ and Java books in the college market place. More
information on their suite of publications can be found here:

  http://www.prenhall.com/deitel

We are presently seeking qualified technical reviewers to
verify that the Deitels' coverage of Python in their forthcoming book is
accurate.  In return, we are offering a token honorarium.

Might you be willing to participate? If not, could you
perhaps suggest a
colleague?

If you are interested, or have any questions, please contact my colleague, Crissy Statuto, at Crissy_Statuto@prenhall.com

Thank you in advance for your assistance and consideration.

Sincerely,
Crissy Statuto


Crissy Statuto
Project Manager, Computer Science
Prentice Hall
One Lake Street- #3F54
Upper Saddle River, NJ  07458
 
Tel:  201-236-6695     Fax:  201-236-7170
Email:  crissy_statuto@prenhall.com





From thomas.heller@ion-tof.com  Tue Jul 24 12:56:03 2001
From: thomas.heller@ion-tof.com (Thomas Heller)
Date: Tue Jul 24 11:56:03 2001
Subject: [Distutils] extra_objects and dependencies
References: <m15P1hF-007oJYC@smtp.web.de> <3B5D769D.88F3033E@gmx.de>
Message-ID: <0b8d01c11459$09dbf720$e000a8c0@thomasnotebook>

From: "Rene Liebscher" <R.Liebscher@gmx.de>
> Juergen Hermann wrote:
> > 
> > Hi!
> > 
> > We have the problem that if you list additional objects as
> > extra_objects in an Extension object, the linker is NOT called when one
> > of these object files changes. Does that count as a bug?
> 
> Changing line 396 in distutils/commands/build_ext.py from
> 
> if not (self.force or newer_group(sources, ext_filename, 'newer')):
> 
> to 
> 
> if not (self.force or newer_group(sources + ext.extra_objects,
> ext_filename, 'newer')):
> 
> might help. (But I have not tested it for myself.)
> Default value of ext.extra_objects is [] so it
> should not influence any other cases.
> 
> 
> If this works someone who has write access to CVS might add it.

The recommended way to make sure this doesn't get forgotten
is to submit this patch to the sourceforge bug or patch tracker.

Thomas




From mal@lemburg.com  Tue Jul 24 16:54:04 2001
From: mal@lemburg.com (M.-A. Lemburg)
Date: Tue Jul 24 15:54:04 2001
Subject: [Distutils] bdist_innoinst ?!
Message-ID: <3B5DD242.71085837@lemburg.com>

Has anyone looked into creating a bdist command for the free
Inno Setup 2 Windows installer ?

	http://www.jrsoftware.org/isdl.htm

Since it provides a command line interface and compiles script
files into setup.exe files, distutils should be able to interface
to it quite easily.

-- 
Marc-Andre Lemburg
CEO eGenix.com Software GmbH
______________________________________________________________________
Consulting & Company:                           http://www.egenix.com/
Python Software:                        http://www.lemburg.com/python/


From Paul.Moore@atosorigin.com  Wed Jul 25 05:14:01 2001
From: Paul.Moore@atosorigin.com (Moore, Paul)
Date: Wed Jul 25 04:14:01 2001
Subject: [Distutils] bdist_innoinst ?!
Message-ID: <714DFA46B9BBD0119CD000805FC1F53B01B5AF2D@UKRUX002.rundc.uk.origin-it.com>

From: M.-A. Lemburg [mailto:mal@lemburg.com]
> Has anyone looked into creating a bdist command for the free
> Inno Setup 2 Windows installer ?

While I don't have any difficulties one way or the other with this idea, I
think one of the important questions would be: What would this installer
offer that the current bdist_wininst does not? (In the context of Python
extensions). If the answer is "nothing much", I'd suggest that having a
single "standard" installer is a good thing. (There are aspects of the
bdist_wininst installer's look and feel that I'm not 100% keen on, but the
complete consistency with all installations *is* nice).

Paul.


From thomas.heller@ion-tof.com  Wed Jul 25 06:49:01 2001
From: thomas.heller@ion-tof.com (Thomas Heller)
Date: Wed Jul 25 05:49:01 2001
Subject: [Distutils] bdist_innoinst ?!
References: <3B5DD242.71085837@lemburg.com>
Message-ID: <0e1801c114ee$e7cd7be0$e000a8c0@thomasnotebook>

> Has anyone looked into creating a bdist command for the free
> Inno Setup 2 Windows installer ?
> 
I was thinking about a bdist_wise in these old days,
but I gave up after bdist_wininst was implemented.

What are you missing?

Thomas



From mal@lemburg.com  Wed Jul 25 06:57:01 2001
From: mal@lemburg.com (M.-A. Lemburg)
Date: Wed Jul 25 05:57:01 2001
Subject: [Distutils] bdist_innoinst ?!
References: <3B5DD242.71085837@lemburg.com> <0e1801c114ee$e7cd7be0$e000a8c0@thomasnotebook>
Message-ID: <3B5E980C.1CD74DA8@lemburg.com>

Thomas Heller wrote:
> 
> > Has anyone looked into creating a bdist command for the free
> > Inno Setup 2 Windows installer ?
> >
> I was thinking about a bdist_wise in these old days,
> but I gave up after bdist_wininst was implemented.
> 
> What are you missing?

I am very satisfied with the existing bdist_wininst, the
only reason for heading into the inno setup direction is
that it would allow more flexible setups, e.g. the user has
more options to choose from, you can wrap packages which 
contain optional subpackages, do full, standard and
customized installs, add auxiliary package installs such as
MDAC or ship MSVC DLLs etc.

bdist_wininst is perfect for pure Python packages and probably
most binary extensions too, but there are a small number
of instances which do require more functionality and since
Inno Setup is free, I thought it would be a good idea to add
support for it to distutils.

-- 
Marc-Andre Lemburg
CEO eGenix.com Software GmbH
______________________________________________________________________
Consulting & Company:                           http://www.egenix.com/
Python Software:                        http://www.lemburg.com/python/


From davida@pobox.com  Wed Jul 25 07:07:01 2001
From: davida@pobox.com (David Arnold)
Date: Wed Jul 25 06:07:01 2001
Subject: [Distutils] bdist_innoinst ?!
In-Reply-To: Your message of "Wed, 25 Jul 2001 11:57:32 +0200."
 <3B5E980C.1CD74DA8@lemburg.com>
Message-ID: <200107251006.f6PA6A708514@xevious.dstc.monash.edu.au>

-->"Marc-Andre" == M -A Lemburg <mal@lemburg.com> writes:

  Marc-Andre> I am very satisfied with the existing bdist_wininst, the
  Marc-Andre> only reason for heading into the inno setup direction is
  Marc-Andre> that it would allow more flexible setups, e.g. the user
  Marc-Andre> has more options to choose from, you can wrap packages
  Marc-Andre> which contain optional subpackages, do full, standard
  Marc-Andre> and customized installs, add auxiliary package installs
  Marc-Andre> such as MDAC or ship MSVC DLLs etc.

we use the Inno Setup (and the Inno Setup Extensions) for our windows
stuff, and it's been very good there (far better than WISE, which we
used to use, on most features).

  Marc-Andre> bdist_wininst is perfect for pure Python packages and
  Marc-Andre> probably most binary extensions too, but there are a
  Marc-Andre> small number of instances which do require more
  Marc-Andre> functionality and since Inno Setup is free, I thought it
  Marc-Andre> would be a good idea to add support for it to distutils.

one feature i would dearly like (and it might even be provided by the
current installer?) is the ability to run unattended installs from the
scheduler.

we do automated nightly build/test stuff, and at the moment, my Python
packages are not tested on windows because i can't find a way to get
the installer to run unattended.

does anyone know if the current bdist_wininst can do this?  i'd be
interested in helping to add it, either via Inno or otherwise.




d


From thomas.heller@ion-tof.com  Wed Jul 25 08:02:38 2001
From: thomas.heller@ion-tof.com (Thomas Heller)
Date: Wed Jul 25 07:02:38 2001
Subject: [Distutils] bdist_innoinst ?!
References: <200107251006.f6PA6A708514@xevious.dstc.monash.edu.au>
Message-ID: <008001c114f9$0a308a10$e000a8c0@thomasnotebook>

From: "David Arnold" <arnold@dstc.monash.edu.au>
> -->"Marc-Andre" == M -A Lemburg <mal@lemburg.com> writes:
>   Marc-Andre> bdist_wininst is perfect for pure Python packages and
>   Marc-Andre> probably most binary extensions too, but there are a
>   Marc-Andre> small number of instances which do require more
>   Marc-Andre> functionality and since Inno Setup is free, I thought it
>   Marc-Andre> would be a good idea to add support for it to distutils.
> 
> one feature i would dearly like (and it might even be provided by the
> current installer?) is the ability to run unattended installs from the
> scheduler.
> 
> we do automated nightly build/test stuff, and at the moment, my Python
> packages are not tested on windows because i can't find a way to get
> the installer to run unattended.
> 
> does anyone know if the current bdist_wininst can do this?  i'd be
> interested in helping to add it, either via Inno or otherwise.
No, it cannot. But it would probably be a useful feature...

Another possibility is the following:
bdist_wininst created exe-Files are also zip-Files,
and can be opened by Winzip and probably also Info-Zip's
unzip program. So you _could_ write a batch file which unzips
the distribution into a certain place.

(That reminds me that I have promised to write more
docs for bdist_wininst. Later, as usual.)

Thomas



From thomas.heller@ion-tof.com  Wed Jul 25 13:01:13 2001
From: thomas.heller@ion-tof.com (Thomas Heller)
Date: Wed Jul 25 12:01:13 2001
Subject: [Distutils] bdist_innoinst ?!
References: <3B5DD242.71085837@lemburg.com> <0e1801c114ee$e7cd7be0$e000a8c0@thomasnotebook> <3B5E980C.1CD74DA8@lemburg.com>
Message-ID: <025e01c11522$afa286a0$e000a8c0@thomasnotebook>

From: "M.-A. Lemburg" <mal@lemburg.com>
> ... customized installs, add auxiliary package installs such as
> MDAC or ship MSVC DLLs etc.

I have the impression that in these times (file system protection
in win2000) it is even more complicated to get it right, or maybe
even impossible to replace/update system dlls. I remember having
looked (some time ago, win95 was current at that time) into the
WISE supplied ODBC install script, IIRC it didn't really look so easy.

Creating an bdist_inno would probably be more or less trivial,
on the other hand distutils would have to be extended to
allow specifying these DLLs.

> 
> bdist_wininst is perfect for pure Python packages and probably
> most binary extensions too, but there are a small number
> of instances which do require more functionality and since
> Inno Setup is free, I thought it would be a good idea to add
> support for it to distutils.

Are you more heading towards installing python extensions together
with their binary dependecies, or towards installing Python
applications (the 'scripts=...' part)?

(IMO creating an inno setup script would be very useful for
py2exe, but this is probably a different issue...)

Thomas



From mal@lemburg.com  Wed Jul 25 13:47:01 2001
From: mal@lemburg.com (M.-A. Lemburg)
Date: Wed Jul 25 12:47:01 2001
Subject: [Distutils] bdist_innoinst ?!
References: <3B5DD242.71085837@lemburg.com> <0e1801c114ee$e7cd7be0$e000a8c0@thomasnotebook> <3B5E980C.1CD74DA8@lemburg.com> <025e01c11522$afa286a0$e000a8c0@thomasnotebook>
Message-ID: <3B5EF77B.2A9CB9D4@lemburg.com>

Thomas Heller wrote:
> 
> From: "M.-A. Lemburg" <mal@lemburg.com>
> > ... customized installs, add auxiliary package installs such as
> > MDAC or ship MSVC DLLs etc.
> 
> I have the impression that in these times (file system protection
> in win2000) it is even more complicated to get it right, or maybe
> even impossible to replace/update system dlls. I remember having
> looked (some time ago, win95 was current at that time) into the
> WISE supplied ODBC install script, IIRC it didn't really look so easy.

True, but all of these installers do try to handle system DLLs
which is way beyond the scope of wininst. I'd say better keep
wininst nice and simple (well, at least the frontend ;-) and
let the big installer packages handle the rest of the scoop.
 
> Creating an bdist_inno would probably be more or less trivial,
> on the other hand distutils would have to be extended to
> allow specifying these DLLs.

Sure, but that wouldn't be much of a problem: you can add
as many options to bdist_inno as you want (and then store
the less often used ones in your setup.cfg file).
 
> > bdist_wininst is perfect for pure Python packages and probably
> > most binary extensions too, but there are a small number
> > of instances which do require more functionality and since
> > Inno Setup is free, I thought it would be a good idea to add
> > support for it to distutils.
> 
> Are you more heading towards installing python extensions together
> with their binary dependecies, or towards installing Python
> applications (the 'scripts=...' part)?

Both; I'd like to ship py2exe style programs using an installer
(which also includes the VC DLLs and maybe MDAC as option) and
complete packages with options for the various subpackages +
the DLLs, EXEs, LIBs etc. they depend on.

Inno Setup should let me do both of these.
 
> (IMO creating an inno setup script would be very useful for
> py2exe, but this is probably a different issue...)

It's a different scope, but not unrelated ;-)

-- 
Marc-Andre Lemburg
CEO eGenix.com Software GmbH
______________________________________________________________________
Company & Consulting:                           http://www.egenix.com/
Python Software:                        http://www.lemburg.com/python/



From tim.one@home.com  Wed Jul 25 15:35:08 2001
From: tim.one@home.com (Tim Peters)
Date: Wed Jul 25 14:35:08 2001
Subject: [Distutils] bdist_innoinst ?!
In-Reply-To: <025e01c11522$afa286a0$e000a8c0@thomasnotebook>
Message-ID: <LNBBLJKPBEHFEDALKOLCAECGLBAA.tim.one@home.com>

[MAL]
> ... customized installs, add auxiliary package installs such as
> MDAC or ship MSVC DLLs etc.

[Thomas Heller]
> I have the impression that in these times (file system protection
> in win2000) it is even more complicated to get it right, or maybe
> even impossible to replace/update system dlls. I remember having
> looked (some time ago, win95 was current at that time) into the
> WISE supplied ODBC install script, IIRC it didn't really look so easy.

After the ancient Wise 5.0a installer PythonLabs still uses kept me up all
night desperately trying to build a 2.2a1 Windows installer that worked,
over the rest of that week I poked away at building an Inno installer for
Python.  The result is in CVS, under PCbuild/python.iss.  It gets most of
the job done, but not all.

I hit a brick wall with Inno when it came to distributing the MSVC runtime,
and with writing to HKLM *or* HKCU (depending on the combo of whether the
user needs admin privs to write to HKLM and whether the user *has* admin
privs).  Inno doesn't appear up to these tasks:  it has no way to query
whether the user is an admin, and no conditionals even if it did.  You can
tell Inno to *require* admin privs, but then the script stops with an error
msg if the user doesn't have them.  All MSVC runtime DLLs must be installed
with Inno's "restartreplace" flag, and that requires admin privs on W2K
boxes.  See

    http://www.jrsoftware.org/ishowto.phtml?a=vc

for the full Inno story here.

I'm not sure how Wise 5.0a gets away with this.  It could be that nobody has
tried to install Python on a W2K box that didn't already have an up-to-date
msvcrt.dll + msvcirt.dll.  Or it could be that Wise tries to overwrite them
and simply ignores the "you can't do that" code that comes back from
MoveFileEx + MOVEFILE_DELAY_UNTIL_REBOOT.  Whatever, it is indeed much
harder than it used to be to redistribute MS runtime components, and Inno
doesn't have a usable handle on it.

> ...
> (IMO creating an inno setup script would be very useful for
> py2exe, but this is probably a different issue...)

In Inno's favor, it's extremely easy to do straightfoward tasks with it, and
its dead-simple script file format seems ideally suited for generating by
program.



From thomas.heller@ion-tof.com  Wed Jul 25 15:49:00 2001
From: thomas.heller@ion-tof.com (Thomas Heller)
Date: Wed Jul 25 14:49:00 2001
Subject: [Distutils] bdist_innoinst ?!
References: <LNBBLJKPBEHFEDALKOLCAECGLBAA.tim.one@home.com>
Message-ID: <054301c1153a$6207cf50$e000a8c0@thomasnotebook>

> [MAL]
> > ... customized installs, add auxiliary package installs such as
> > MDAC or ship MSVC DLLs etc.
> 
> [Thomas Heller]
> > I have the impression that in these times (file system protection
> > in win2000) it is even more complicated to get it right, or maybe
> > even impossible to replace/update system dlls. I remember having
> > looked (some time ago, win95 was current at that time) into the
> > WISE supplied ODBC install script, IIRC it didn't really look so easy.
> 

From: "Tim Peters" <tim.one@home.com>
> After the ancient Wise 5.0a installer PythonLabs still uses kept me up all
> night desperately trying to build a 2.2a1 Windows installer that worked,

What did change in 2.2a1 compared to 2.1, 2.0, or 1.5.2 (which all seem
to use Wise5.0)? The version of MSVCRT.DLL and MSVCIRT.DLL?
I deinstall and reinstall all of these more or less regularly
in Win2k Prof (probably SP1) with admin rights without any problems.
This is from my recent 2.2a1 installation log:

Version: Following file not copied.
 File Copy: C:\WINNT\System32\MSVCIRT.DLL
File Copy: C:\WINNT\System32\MSVCRT.DLL

Does this mean that wise overwrote MSVCRT.DLL, but did _not_ overwrite
MSVCIRT.DLL? Note that I never had to reboot after a Python
installation.

Thomas




From mal@lemburg.com  Wed Jul 25 16:30:01 2001
From: mal@lemburg.com (M.-A. Lemburg)
Date: Wed Jul 25 15:30:01 2001
Subject: [Distutils] bdist_innoinst ?!
References: <LNBBLJKPBEHFEDALKOLCAECGLBAA.tim.one@home.com>
Message-ID: <3B5F1DAD.B36BBF6F@lemburg.com>

Tim Peters wrote:
> 
> [MAL]
> > ... customized installs, add auxiliary package installs such as
> > MDAC or ship MSVC DLLs etc.
> 
> [Thomas Heller]
> > I have the impression that in these times (file system protection
> > in win2000) it is even more complicated to get it right, or maybe
> > even impossible to replace/update system dlls. I remember having
> > looked (some time ago, win95 was current at that time) into the
> > WISE supplied ODBC install script, IIRC it didn't really look so easy.
> 
> After the ancient Wise 5.0a installer PythonLabs still uses kept me up all
> night desperately trying to build a 2.2a1 Windows installer that worked,
> over the rest of that week I poked away at building an Inno installer for
> Python.  The result is in CVS, under PCbuild/python.iss.  It gets most of
> the job done, but not all.
> 
> I hit a brick wall with Inno when it came to distributing the MSVC runtime,
> and with writing to HKLM *or* HKCU (depending on the combo of whether the
> user needs admin privs to write to HKLM and whether the user *has* admin
> privs).  Inno doesn't appear up to these tasks:  it has no way to query
> whether the user is an admin, and no conditionals even if it did.  You can
> tell Inno to *require* admin privs, but then the script stops with an error
> msg if the user doesn't have them.  All MSVC runtime DLLs must be installed
> with Inno's "restartreplace" flag, and that requires admin privs on W2K
> boxes.  See
> 
>     http://www.jrsoftware.org/ishowto.phtml?a=vc
> 
> for the full Inno story here.

I've just skimmed the Inno docs, but it seems that you can
work around these issues by providing a custom little EXE which
does all the tricks you want (according to the docs you just 
have to place it into the [Run] section).

	http://www.jrsoftware.org/ishowto.phtml?a=custom

You might even be able to place a call to vcredist.exe into
that section (I just don't know how to stop the .exe from
giving me the reboot box).

-- 
Marc-Andre Lemburg
CEO eGenix.com Software GmbH
______________________________________________________________________
Company & Consulting:                           http://www.egenix.com/
Python Software:                        http://www.lemburg.com/python/


From thomas.heller@ion-tof.com  Wed Jul 25 16:44:08 2001
From: thomas.heller@ion-tof.com (Thomas Heller)
Date: Wed Jul 25 15:44:08 2001
Subject: [Distutils] bdist_innoinst ?!
References: <LNBBLJKPBEHFEDALKOLCAECGLBAA.tim.one@home.com> <3B5F1DAD.B36BBF6F@lemburg.com>
Message-ID: <05c701c11542$13a91f00$e000a8c0@thomasnotebook>

From: "M.-A. Lemburg" <mal@lemburg.com>
> 
> You might even be able to place a call to vcredist.exe into
> that section (I just don't know how to stop the .exe from
> giving me the reboot box).
>From the MS KB Article Q259403:
Vcredist.exe supports the following command-line switches: 
 no switches = non-quiet mode, displays progress bar and reboot prompt
 /q = semi-quiet mode, displays reboot message, and no progress bar
 /q /r:n = no reboot message or progress bar 

Thomas



From tim.one@home.com  Wed Jul 25 17:11:01 2001
From: tim.one@home.com (Tim Peters)
Date: Wed Jul 25 16:11:01 2001
Subject: [Distutils] bdist_innoinst ?!
In-Reply-To: <3B5F1DAD.B36BBF6F@lemburg.com>
Message-ID: <LNBBLJKPBEHFEDALKOLCEEDCLBAA.tim.one@home.com>

[MAL]
> I've just skimmed the Inno docs, but it seems that you can
> work around these issues by providing a custom little EXE which
> does all the tricks you want (according to the docs you just
> have to place it into the [Run] section).
>
> 	http://www.jrsoftware.org/ishowto.phtml?a=custom
>
> You might even be able to place a call to vcredist.exe into
> that section (I just don't know how to stop the .exe from
> giving me the reboot box).

http://support.microsoft.com/support/kb/articles/Q259/4/03.ASP

    [vcrdist.exe]] is not a recommended redistribution method for the
    preceding files.  This package does not communicate error messages
    back to the program or user that is starting Vcredist.exe.
    Therefore, Microsoft highly recommends that programs starting
    Vcredist.exe first check for available disk space (approximately 10
    MB), read-only system files, administrator privileges, and a valid
    TEMP directory. The absence of any of these prerequisites can
    cause this package to incorrectly install some of the files onto
    the target system.

IOW, it doesn't solve the problem, although it may be a step on the way.
Would also add another ~2Mb to the download -- it ships stuff Python has no
use for (especiall the large MFC DLLs).



From tim.one@home.com  Wed Jul 25 17:39:01 2001
From: tim.one@home.com (Tim Peters)
Date: Wed Jul 25 16:39:01 2001
Subject: [Distutils] bdist_innoinst ?!
In-Reply-To: <054301c1153a$6207cf50$e000a8c0@thomasnotebook>
Message-ID: <LNBBLJKPBEHFEDALKOLCEEDFLBAA.tim.one@home.com>

[Thomas Heller]
> What did change in 2.2a1 compared to 2.1, 2.0, or 1.5.2 (which all seem
> to use Wise5.0)?

Every Python Windows installer ever released used Wise 5.0a.  I never did
figure out "what changed" in 2.2a1, although it *appeared* to be related to
one of {total number of files, total size of files}; e.g., if I left the
docs out, the installer worked fine.  Else it died instantly upon launch
with a GPF in GLBSSTUB.EXE (a Wise file), and Dr Watson always froze solid
while trying to make an after-fault snapshot.  After hours and hours of
thrashing at random, it eventually fixed itself for no identifiable reason
(the last thing I did before it started working again was nuke my entire
PCbuild directory, refetch everything from SourceForge, and rebuild
everything from scratch; best *guess* is that I somehow got a corrupted .wsm
file).

However, since Win2K was released, I've seen a sharp increase in the
frequency of install failure reports.  It still only amounts to a few dozen
total, but the trend is clear, and so is that we have no real handle on most
of the new breed of failures.

> The version of MSVCRT.DLL and MSVCIRT.DLL?

No; I believe they're the same as in 2.1.

> I deinstall and reinstall all of these more or less regularly
> in Win2k Prof (probably SP1) with admin rights without any problems.

Same here.  We appear to be the norm, but others aren't so lucky.

> This is from my recent 2.2a1 installation log:
>
> Version: Following file not copied.
>  File Copy: C:\WINNT\System32\MSVCIRT.DLL
> File Copy: C:\WINNT\System32\MSVCRT.DLL
>
> Does this mean that wise overwrote MSVCRT.DLL, but did _not_ overwrite
> MSVCIRT.DLL?

Your understanding of undocumented English matches mine <wink>:  it thought
your msvcirt.dll was at least as new as the one shipped, but not your
msvcrt.dll.

> Note that I never had to reboot after a Python installation.

My understanding at one point (this stuff is, as I bet you know all too
well, damned hard to track down with confidence!) is that if you tried to
replace any of the DLLs MS cares about, it wouldn't complain on Win2K, but
silently undo it.

Life would sure be simpler if Python installed the MS DLLs it needs under
its own directory.  I'm not enough of a Windows-head to know why that's
impossible, though <wink>.



From robin@alldunn.com  Wed Jul 25 23:46:00 2001
From: robin@alldunn.com (Robin Dunn)
Date: Wed Jul 25 22:46:00 2001
Subject: [Distutils] bdist_innoinst ?!
References: <LNBBLJKPBEHFEDALKOLCAECGLBAA.tim.one@home.com>
Message-ID: <00a101c1157c$fa764ef0$0100a8c0@Rogue>

>
> I hit a brick wall with Inno when it came to distributing the MSVC
runtime,
> and with writing to HKLM *or* HKCU (depending on the combo of whether the
> user needs admin privs to write to HKLM and whether the user *has* admin
> privs).  Inno doesn't appear up to these tasks:  it has no way to query
> whether the user is an admin, and no conditionals even if it did.

You can get conditionals and other scripting capabilites with the InnoSetup
Extensions available at http://www.wintax.nl/isx/.  I use it a tiny bit in
the wxPython installer, but I've heard that it can do a whole lot more.

--
Robin Dunn
Software Craftsman
robin@AllDunn.com       Java give you jitters?
http://wxPython.org      Relax with wxPython!






From tim.one@home.com  Thu Jul 26 01:21:00 2001
From: tim.one@home.com (Tim Peters)
Date: Thu Jul 26 00:21:00 2001
Subject: [Distutils] bdist_innoinst ?!
In-Reply-To: <00a101c1157c$fa764ef0$0100a8c0@Rogue>
Message-ID: <LNBBLJKPBEHFEDALKOLCKEFALBAA.tim.one@home.com>

[Robin Dunn]
> You can get conditionals and other scripting capabilites with the
> InnoSetup Extensions available at http://www.wintax.nl/isx/.  I use
> it a tiny bit in the wxPython installer, but I've heard that it can
> do a whole lot more.

Ya, I looked at that.  That's what Python needs:  to ship an installer with
an embedded Pascal interpreter <wink>.

Wise kindly offered to let PythonLabs use InstallerMaster 8, and I just got
the box from UPS today.  So my strong bet is that's the future for the
PythonLabs Windows installer.  All you other suckers are on your own <wink>.

Seriously, I hope *someone* picks up python.iss and finishes an Inno
installer for Python, Pascal-driven or not.

BTW, I tried MS's Visual Installer (currently free, no idea whether that
will last) MSI authoring tool, and limped away screaming in terror.  If
that's the future of Windows installer technology, I'm glad I still have a
few friends left in the Linux world ...



From mlit@ametrano.net  Thu Jul 26 04:41:52 2001
From: mlit@ametrano.net (Ferdinando Ametrano)
Date: Thu Jul 26 03:41:52 2001
Subject: [Distutils] bdist_innoinst ?!
In-Reply-To: <LNBBLJKPBEHFEDALKOLCKEFALBAA.tim.one@home.com>
References: <00a101c1157c$fa764ef0$0100a8c0@Rogue>
Message-ID: <5.1.0.14.2.20010726093339.00a70e30@mail.ametrano.net>

Maybe I'm naif, but how does the Null Soft Install System 
(http://www.nullsoft.com/free/nsis/) compare with Inno?

I use NSIS to distribute QuantLib (http://quantlib.org), and bdist_wininst 
to distribute QuantLib-Python

ciao -- Nando



From mal@lemburg.com  Thu Jul 26 05:38:00 2001
From: mal@lemburg.com (M.-A. Lemburg)
Date: Thu Jul 26 04:38:00 2001
Subject: [Distutils] bdist_innoinst ?!
References: <LNBBLJKPBEHFEDALKOLCKEFALBAA.tim.one@home.com>
Message-ID: <3B5FD736.635EECFC@lemburg.com>

Tim Peters wrote:
> 
> [Robin Dunn]
> > You can get conditionals and other scripting capabilites with the
> > InnoSetup Extensions available at http://www.wintax.nl/isx/.  I use
> > it a tiny bit in the wxPython installer, but I've heard that it can
> > do a whole lot more.
> 
> Ya, I looked at that.  That's what Python needs:  to ship an installer with
> an embedded Pascal interpreter <wink>.

Since Inno is written in Delphi and there is a really nice Delphi-Python
gateway out there, why not add an embedded Python interpreter to Inno ?!

Would be sort of cool ... you install Python by using a Python script
to tweak a Delphi program into doing the right thing. Python will
then finally learn to boot itself ;-)
 
> Wise kindly offered to let PythonLabs use InstallerMaster 8, and I just got
> the box from UPS today.  So my strong bet is that's the future for the
> PythonLabs Windows installer.  All you other suckers are on your own <wink>.

I wonder why you guys didn't pick up a new release from Wise 
earlier... the many hours you spent on getting Wise5 to work without
GPF would certainly have paid up for the new version.
 
> Seriously, I hope *someone* picks up python.iss and finishes an Inno
> installer for Python, Pascal-driven or not.
> 
> BTW, I tried MS's Visual Installer (currently free, no idea whether that
> will last) MSI authoring tool, and limped away screaming in terror.  If
> that's the future of Windows installer technology, I'm glad I still have a
> few friends left in the Linux world ...

-- 
Marc-Andre Lemburg
CEO eGenix.com Software GmbH
______________________________________________________________________
Consulting & Company:                           http://www.egenix.com/
Python Software:                        http://www.lemburg.com/python/


From mal@lemburg.com  Thu Jul 26 05:39:57 2001
From: mal@lemburg.com (M.-A. Lemburg)
Date: Thu Jul 26 04:39:57 2001
Subject: [Distutils] bdist_innoinst ?!
References: <LNBBLJKPBEHFEDALKOLCEEDCLBAA.tim.one@home.com>
Message-ID: <3B5FD17F.968EE2B0@lemburg.com>

Tim Peters wrote:
> 
> [MAL]
> > I've just skimmed the Inno docs, but it seems that you can
> > work around these issues by providing a custom little EXE which
> > does all the tricks you want (according to the docs you just
> > have to place it into the [Run] section).
> >
> >       http://www.jrsoftware.org/ishowto.phtml?a=custom
> >
> > You might even be able to place a call to vcredist.exe into
> > that section (I just don't know how to stop the .exe from
> > giving me the reboot box).
> 
> http://support.microsoft.com/support/kb/articles/Q259/4/03.ASP
> 
>     [vcrdist.exe]] is not a recommended redistribution method for the
>     preceding files.  This package does not communicate error messages
>     back to the program or user that is starting Vcredist.exe.
>     Therefore, Microsoft highly recommends that programs starting
>     Vcredist.exe first check for available disk space (approximately 10
>     MB), read-only system files, administrator privileges, and a valid
>     TEMP directory. The absence of any of these prerequisites can
>     cause this package to incorrectly install some of the files onto
>     the target system.

Zzhhhh. No idea why MS ships vcredist.exe in the first place then...

IMHO, the best way to upgrade Windows still is installing the latest
IE version (and then uninstalling it again)... would cost an extra
15MB, though, but who cares ;-)
 
> IOW, it doesn't solve the problem, although it may be a step on the way.
> Would also add another ~2Mb to the download -- it ships stuff Python has no
> use for (especiall the large MFC DLLs).

Well, what I wanted to say was that Inno does allow you to tweak it
into doing stuff which it wasn't built for by providing your own little
EXE which implements the needed black magic and mamba voodoo.

-- 
Marc-Andre Lemburg
CEO eGenix.com Software GmbH
______________________________________________________________________
Consulting & Company:                           http://www.egenix.com/
Python Software:                        http://www.lemburg.com/python/




From mal@lemburg.com  Thu Jul 26 05:47:23 2001
From: mal@lemburg.com (M.-A. Lemburg)
Date: Thu Jul 26 04:47:23 2001
Subject: [Distutils] bdist_innoinst ?!
References: <00a101c1157c$fa764ef0$0100a8c0@Rogue> <5.1.0.14.2.20010726093339.00a70e30@mail.ametrano.net>
Message-ID: <3B5FD941.BC8C7EBA@lemburg.com>

Ferdinando Ametrano wrote:
> 
> Maybe I'm naif, but how does the Null Soft Install System
> (http://www.nullsoft.com/free/nsis/) compare with Inno?

No idea, to tell you the truth... bdist_nsis anyone ? (I wouldn't
mind having a whole set of supported installers in distutils,
Tim might even come up with a bdist_Wise_InstallMaster8 installer ;-)
 
> I use NSIS to distribute QuantLib (http://quantlib.org), and bdist_wininst
> to distribute QuantLib-Python

-- 
Marc-Andre Lemburg
CEO eGenix.com Software GmbH
______________________________________________________________________
Consulting & Company:                           http://www.egenix.com/
Python Software:                        http://www.lemburg.com/python/


From tim@digicool.com  Thu Jul 26 13:40:03 2001
From: tim@digicool.com (Tim Peters)
Date: Thu Jul 26 12:40:03 2001
Subject: [Distutils] bdist_innoinst ?!
In-Reply-To: <3B5FD736.635EECFC@lemburg.com>
Message-ID: <BIEJKCLHCIOIHAGOKOLHGELPCDAA.tim@digicool.com>

[MAL]
> Since Inno is written in Delphi and there is a really nice Delphi-
> Python gateway out there, why not add an embedded Python interpreter
> to Inno ?!

I've got no time for that, but it's a fine idea.

> ...
> I wonder why you guys didn't pick up a new release from Wise
> earlier... the many hours you spent on getting Wise5 to work without
> GPF would certainly have paid up for the new version.

The version of Wise they just sent is US$800 retail, and street price
doesn't seem to be significantly lower.  That's a hard sell without Windows
revenue to offset it (and Open Source management is even more delusional
than commercial-shop mgmt about the economics of throwing programmer-months
at problems for which top-tier solutions *could* be purchased at once
<wink>).  Wise was happy to accommodate once I reached the right person, but
achieving the latter stretched over months.



From thomas.heller@ion-tof.com  Thu Jul 26 14:18:03 2001
From: thomas.heller@ion-tof.com (Thomas Heller)
Date: Thu Jul 26 13:18:03 2001
Subject: [Distutils] bdist_innoinst ?!
References: <LNBBLJKPBEHFEDALKOLCKEFALBAA.tim.one@home.com> <3B5FD736.635EECFC@lemburg.com>
Message-ID: <056a01c115f6$cf0e3f00$e000a8c0@thomasnotebook>

M.-A. Lemburg:
> Tim Peters wrote:
> > 
> > [Robin Dunn]
> > > You can get conditionals and other scripting capabilites with the
> > > InnoSetup Extensions available at http://www.wintax.nl/isx/.  I use
> > > it a tiny bit in the wxPython installer, but I've heard that it can
> > > do a whole lot more.
> > 
> > Ya, I looked at that.  That's what Python needs:  to ship an installer with
> > an embedded Pascal interpreter <wink>.
> 
> Since Inno is written in Delphi and there is a really nice Delphi-Python
> gateway out there, why not add an embedded Python interpreter to Inno ?!
> 
> Would be sort of cool ... you install Python by using a Python script
> to tweak a Delphi program into doing the right thing. Python will
> then finally learn to boot itself ;-)

Using Python to install the DLLs it needs to run ;-?

In this case maybe it would easier to use bdist_wininst,
it already _has_ Python embedded, and it could export win32api
functions needed to Python.

Thomas



From gustav@morpheus.demon.co.uk  Sun Jul 29 16:37:00 2001
From: gustav@morpheus.demon.co.uk (Paul Moore)
Date: Sun Jul 29 15:37:00 2001
Subject: [Distutils] Distutils changes for PEP 250
In-Reply-To: <g58jltk8dq6umbk46r4crkq51rvbj8l7vb@4ax.com>
References: <g58jltk8dq6umbk46r4crkq51rvbj8l7vb@4ax.com>
Message-ID: <eip8mt8rno831or0lg6tj8ud309pr5m7l5@4ax.com>

On Sat, 21 Jul 2001 17:21:25 +0100, Paul Moore =
<gustav@morpheus.demon.co.uk>
wrote:

>I think there's now been enough time to ensure that no further issues =
are going
>to come out. I therefore enclose a patch, which should, I believe, =
capture all
>the issues.

I just checked CVS, and this hasn't gone in yet.

I've submitted it to the Sourceforge patch manager so that it doesn't get=
 lost -
it's patch ID 445744. (Submitted by "nobody", as I couldn't get my login =
to work
:-() It still requires Thomas' wininst patch to be complete.

Maybe this is what I should have done in the first place?

Paul.


From paul@pfdubois.com  Tue Jul 31 20:52:02 2001
From: paul@pfdubois.com (Paul F. Dubois)
Date: Tue Jul 31 19:52:02 2001
Subject: [Distutils] Help: need info on Fortran/C mixing on Windows
Message-ID: <ADEOIFHFONCLEEPKCACCOEIKCLAA.paul@pfdubois.com>

Any fellow nummies and Pythonistas out there with experience using Digital
Fortran on Windows?

I'm trying to get Pyfort to work with Visual Fortran / Visual C++ on
Windows. I am not usually a Windows developer so I do not know how to do
things like look at an object file to see what names are in it (as I could
do with nm on Unix). I have discovered that by including
c$DEC ATTRIBUTES C:: foo
in my Fortran, where foo is the name of my Fortran function, that my missing
external for foo disappears. This is not really ok as I want to be able to
link to unmodified Fortran files that have simply been compiled into a
foostuff.lib file.

I need information such as:

How to get the names to match up, or what name to generate in my C to
correspond to the Fortran;

Which library to load with: I've tried dfor.lib and dformd.lib, in the
context of running a python extension link through distutils, and both
complain vociferously about library conflicts.

If this was my working life I could afford to put in the time to figure all
this out, but this is pro bono publico and I would appreciate your tolerance
of my asking for help.

Even just your Makefile or setup.py from a successful project of this type
would be a big help.

Thanks,

Paul Dubois