From mal@lemburg.com Sat Mar 1 05:08:02 2003
From: mal@lemburg.com (M.-A. Lemburg)
Date: Sat Mar 1 05:08:02 2003
Subject: [Distutils] More documentation for setup meta-data
In-Reply-To: <20030228212124.B27766@nyman.amk.ca>
References: <200302271218.46287.rjones@ekit-inc.com> <200302280851.52571.rjones@ekit-inc.com> <3E5F8CAC.8010000@lemburg.com> <200303011034.58921.rjones@ekit-inc.com> <20030228212124.B27766@nyman.amk.ca>
Message-ID: <3E608604.8090202@lemburg.com>
A.M. Kuchling wrote:
> On Sat, Mar 01, 2003 at 10:34:58AM +1100, Richard Jones wrote:
>
>>[cc'ed only to distutils now]
>>
>>On Sat, 1 Mar 2003 03:22 am, M.-A. Lemburg wrote:
>>
>>>Uhm, it doesn't work in Python 2.3... that's why I was asking.
>
> Huh? I thought I checked all the relevant bits in before 2.3alpha2,
> and it seems to work for me. (It wasn't in 2.3alpha1.) MAL, when you
> say "it doesn't work", what do you mean?
Well, if you pass download_url="something" to setup() then
you get an error saying that this is an unknown parameter.
Unless I have misunderstood something, that was the intended
purpose of download_url, right ? (and it should then end
up in the meta information just like the classifiers)
--
Marc-Andre Lemburg
eGenix.com
Professional Python Software directly from the Source (#1, Mar 01 2003)
>>> Python/Zope Products & Consulting ... http://www.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
Python UK 2003, Oxford: 31 days left
EuroPython 2003, Charleroi, Belgium: 115 days left
From mal@lemburg.com Sat Mar 1 05:15:18 2003
From: mal@lemburg.com (M.-A. Lemburg)
Date: Sat Mar 1 05:15:18 2003
Subject: [Distutils] installing data files and headers
In-Reply-To: <20030228211409.A27766@nyman.amk.ca>
References: <1046446257.29989.79.camel@localhost.localdomain> <20030228211409.A27766@nyman.amk.ca>
Message-ID: <3E6087BF.2000306@lemburg.com>
A.M. Kuchling wrote:
> On Fri, Feb 28, 2003 at 10:31:00AM -0500, Jeremy Hylton wrote:
>
>>Another problem we've been struggling with for Zope projects is that
>>distutils really only installs Python modules and extensions. It's
>>support for data files and C header files is pretty limited. We've got
>
>
> Good idea. We have a similar subclass for Quixote that installs *.ptl
> files, and it's a common need.
Dito here for various documentation files, licenses etc.
The problem seems to be that all of us have slightly different
requirements here, so perhaps there simply isn't a one-fits-all
implementation.
>>installed, so that you don't install .py~ files. One possibility is to
>>explicitly list the file extensions that constitute installable data.
>>We did that for Zope3, but the list of extensions ended up being fairly
>>long.
>
> Well, what are the options?
>
> 1) List extensions.
> 2) Explicitly list pathnames for additional files.
> 3) A MANIFEST.in-like mini-language for specifying which files should
> be installed.
> 4) Automatically add things in package directories that
> aren't obviously irrelevant (*~, *.pyc, CVS, .svn).
>
> Any other ideas?
>
> 4) probably offers too little control, and 3) might be too much, and
> adds yet another file to write. What if both 1) and 2) were
> supported, say, like this:
>
> setup(...
> package_files=['zope/app/config.xml', 'zope/app/dtd.xml'],
> package_patterns=['*.cfg'],
> )
>
> So this adds all *.cfg files in any package directory, and the two XML
> files. We could also allow arbitrary filenames in the 'py_modules'
> list, but then the very name 'py_modules' is misleading, so IMHO
> that's a bad idea.
>
> One nit is that packages are identified as 'zope.app' in the
> 'packages' and 'package_dir' keywords. build_py will have to mess
> around with the package_files strings, but hopefully that won't be too
> difficult to get right.
Why not merge package_files and package_patterns into one
list. Then use glob.glob() to work this into a list of
single filenames.
The downside with this proposal is that you'll have to add
MANIFEST.in rules for these files as well...
>>The other problem we have is with header files. We'd like to have .h
>>files that are installed inside a directory in /usr/local/include. For
>
> Why isn't installing the headers in /usr/local/python2.2/persistence
> OK? Are these headers completely independent of Python (e.g. for a
> standalone C library)?
FWIW, I usually install the header files right along side the
package's .so files. This makes it very easy for others to
find the locations of the installed headers and avoids any
name clashes.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Software directly from the Source (#1, Mar 01 2003)
>>> Python/Zope Products & Consulting ... http://www.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
Python UK 2003, Oxford: 31 days left
EuroPython 2003, Charleroi, Belgium: 115 days left
From mal@lemburg.com Sat Mar 1 05:21:04 2003
From: mal@lemburg.com (M.-A. Lemburg)
Date: Sat Mar 1 05:21:04 2003
Subject: [Distutils] More documentation for setup meta-data
In-Reply-To: <200303011034.58921.rjones@ekit-inc.com>
References: <200302271218.46287.rjones@ekit-inc.com> <200302280851.52571.rjones@ekit-inc.com> <3E5F8CAC.8010000@lemburg.com> <200303011034.58921.rjones@ekit-inc.com>
Message-ID: <3E608963.50308@lemburg.com>
Richard Jones wrote:
> [cc'ed only to distutils now]
>>>Note that I would like to see an alternative system that is used to
>>>disseminate packages which uses a set of mirrors similar to CPAN. There's
>>>an accepted naming system so that the package may be found just using the
>>>package name and version, and a fatch command that attempts to download
>>>the package from one or more of the mirrors (depending on availability).
>>>PyPI then supplies a list of the mirror sites. Distutils may also offer
>>>an upload command, to make life even easier for the package maintainer.
>>>No need to maintain download urls or even download sites. The kicker with
>>>this plan is the provision of the bandwidth. The other elements of it are
>>>... well, trivial. They could be implemented before 2.3 is released.
>>
>>If you intend to use the download_url for this purpose, then
>>you ought to reserve it's usage for this now. Otherwise,
>>people will simply put a link to the download web-site
>>into this field.
>
> I think that the download_url and download-mirrors approaches are quite
> independant. I guess though that download_url would specify a directory, not
> a file. That would then fit in with the above scheme. Then users wouldn't
> necessarily have to upload their package to the network-of-mirrors.
The download mirrors idea is fine, but it may not always be
what package authors want to use, e.g. companies selling Python
products may want to have complete control over the sites where
you can download their code. The same is true for touchy things
like crypto code.
Even with the mirror idea you still need to tell the system which
files have been uploaded and for which platforms these
are intended (note that not all package authors use the
default distutils naming scheme for files).
The idea with a central download file specification would
solve all of these problems by being explicit about the
names and locations. You only need one URL for this file
and that's why I proposed to use the download_url for this.
Perhaps it needs to be renamed to 'download_spec_url'.
> I'm between jobs at the moment, and have unsubscribed from python-list. Would
> someone else like to ask there for offers of mirror space? Just so we can see
> how viable the approach is? I don't believe that creosote will be useful
> (from what people have said in passing) - but that's ok. I'm not completely
> up to speed with mirroring - can it be done in such a way that there's no
> central "master" server? Or will we have to nominate one?
Why start with a complicated system ? IMHO, it's much better
first getting the already not very easy task of finding
the right download URL in place. Then you can automate this
by setting up a server system and point the download_spec_url
to that server (which then takes over management of the
entries in whatever method is needed).
--
Marc-Andre Lemburg
eGenix.com
Professional Python Software directly from the Source (#1, Mar 01 2003)
>>> Python/Zope Products & Consulting ... http://www.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
Python UK 2003, Oxford: 31 days left
EuroPython 2003, Charleroi, Belgium: 115 days left
From richardjones@optushome.com.au Sat Mar 1 05:52:02 2003
From: richardjones@optushome.com.au (Richard Jones)
Date: Sat Mar 1 05:52:02 2003
Subject: [Distutils] More documentation for setup meta-data
In-Reply-To: <3E608963.50308@lemburg.com>
References: <200302271218.46287.rjones@ekit-inc.com> <200303011034.58921.rjones@ekit-inc.com> <3E608963.50308@lemburg.com>
Message-ID: <200303012151.43387.richardjones@optushome.com.au>
[Sorry, I just noticed that my mailer was auto-setting my send identity to=
=20
rjones@ekit - which was my email address until yesterday. I've fixed it now=
=2E=20
My apologies to anyone who received a bounce message!]
On Sat, 1 Mar 2003 09:20 pm, M.-A. Lemburg wrote:
> Richard Jones wrote:
> > [cc'ed only to distutils now]
> >
> >>>Note that I would like to see an alternative system that is used to
> >>>disseminate packages which uses a set of mirrors similar to CPAN.
> >>> There's an accepted naming system so that the package may be found ju=
st
> >>> using the package name and version, and a fatch command that attempts
> >>> to download the package from one or more of the mirrors (depending on
> >>> availability). PyPI then supplies a list of the mirror sites. Distuti=
ls
> >>> may also offer an upload command, to make life even easier for the
> >>> package maintainer. No need to maintain download urls or even download
> >>> sites. The kicker with this plan is the provision of the bandwidth. T=
he
> >>> other elements of it are ... well, trivial. They could be implemented
> >>> before 2.3 is released.
> >>
> >>If you intend to use the download_url for this purpose, then
> >>you ought to reserve it's usage for this now. Otherwise,
> >>people will simply put a link to the download web-site
> >>into this field.
> >
> > I think that the download_url and download-mirrors approaches are quite
> > independant. I guess though that download_url would specify a directory,
> > not a file. That would then fit in with the above scheme. Then users
> > wouldn't necessarily have to upload their package to the
> > network-of-mirrors.
>
> The download mirrors idea is fine, but it may not always be
> what package authors want to use, e.g. companies selling Python
> products may want to have complete control over the sites where
> you can download their code. The same is true for touchy things
> like crypto code.
Yep, hence my comment that the download_url and download-mirrors approaches=
=20
are quite independant.
> Even with the mirror idea you still need to tell the system which
> files have been uploaded and for which platforms these
> are intended (note that not all package authors use the
> default distutils naming scheme for files).
I think this could be worked around by having the file submission mechanism=
=20
force the filename to follow a specific pattern.
> The idea with a central download file specification would
> solve all of these problems by being explicit about the
> names and locations. You only need one URL for this file
> and that's why I proposed to use the download_url for this.
My argument is that the download file spec system would be quite complex fo=
r=20
the end user to work with. Well, at least I can't think of a reasonable set=
up=20
=2D but perhaps you have :)
> Perhaps it needs to be renamed to 'download_spec_url'.
Hurm - we could just accept that a download url with a specific suffix is a=
=20
spec (eg. .pkgspec)? We could go as far as say that if it's an XML file (ie=
=2E=20
=2Exml), then it's a download spec. I'm pre-supposing XML, of course, when =
the=20
INI format would probably be enough. Again, I think I'd like to see some mo=
re=20
flesh on your proposal (especially the bits about making it as simple as=20
possible for the package maintainer) before I jump on the band-wagon :)
Richard
From mal@lemburg.com Sat Mar 1 07:02:01 2003
From: mal@lemburg.com (M.-A. Lemburg)
Date: Sat Mar 1 07:02:01 2003
Subject: [Distutils] More documentation for setup meta-data
In-Reply-To: <200303012151.43387.richardjones@optushome.com.au>
References: <200302271218.46287.rjones@ekit-inc.com> <200303011034.58921.rjones@ekit-inc.com> <3E608963.50308@lemburg.com> <200303012151.43387.richardjones@optushome.com.au>
Message-ID: <3E60A0DC.7000004@lemburg.com>
Richard Jones wrote:
>>>I think that the download_url and download-mirrors approaches are quite
>>>independant. I guess though that download_url would specify a directory,
>>>not a file. That would then fit in with the above scheme. Then users
>>>wouldn't necessarily have to upload their package to the
>>>network-of-mirrors.
>>
>>The download mirrors idea is fine, but it may not always be
>>what package authors want to use, e.g. companies selling Python
>>products may want to have complete control over the sites where
>>you can download their code. The same is true for touchy things
>>like crypto code.
>
> Yep, hence my comment that the download_url and download-mirrors approaches
> are quite independant.
>
>>Even with the mirror idea you still need to tell the system which
>>files have been uploaded and for which platforms these
>>are intended (note that not all package authors use the
>>default distutils naming scheme for files).
>
> I think this could be worked around by having the file submission mechanism
> force the filename to follow a specific pattern.
You can do that for the mirror type approach, but certainly
not for the download_spec_url approach. While distutils
already goes a long way in trying to add enough information
to the filename to be able to identify the right one to
download, this is sometimes not enough, e.g. RPM names
do not include the Python version per default, or you
may want to add a OS specific tag to the name (like
"suse_8.rpm").
The specification file would make this information machine
readable and thus enable a download mechanism to choose
the right version for download.
>>The idea with a central download file specification would
>>solve all of these problems by being explicit about the
>>names and locations. You only need one URL for this file
>>and that's why I proposed to use the download_url for this.
>
> My argument is that the download file spec system would be quite complex for
> the end user to work with. Well, at least I can't think of a reasonable setup
> - but perhaps you have :)
Not at all: by letting the distutils command read the spec
file, it can make most if not all decisions automatically.
In the end, the end user will just issue:
python pypi.py install pyxml
and the system will do the rest (talk to the PyPI server,
fetch the download spec, identify the right download URL,
find a usable mirror, download the prebuilt binary
distribution and install it).
>>Perhaps it needs to be renamed to 'download_spec_url'.
>
> Hurm - we could just accept that a download url with a specific suffix is a
> spec (eg. .pkgspec)? We could go as far as say that if it's an XML file (ie.
> .xml), then it's a download spec. I'm pre-supposing XML, of course, when the
> INI format would probably be enough. Again, I think I'd like to see some more
> flesh on your proposal (especially the bits about making it as simple as
> possible for the package maintainer) before I jump on the band-wagon :)
Have a look at the ActiveState PPD format (used by their PPM
system to find the right download files):
"""
eGenix mx Extensions for Python - Base Distribution
The eGenix mx Extension Series are a collection of
Python extensions written in ANSI C and Python
which provide a large spectrum of useful additions
to everyday Python programming.
The Base Distribution includes the Open Source subpackages
of the series and is needed by all other add-on
packages of the series.
This software is brought to you by eGenix.com and
distributed under the eGenix.com Public License.
Marc-Andre Lemburg (mal@egenix.com)
"""
I think we can build on that.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Software directly from the Source (#1, Mar 01 2003)
>>> Python/Zope Products & Consulting ... http://www.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
Python UK 2003, Oxford: 31 days left
EuroPython 2003, Charleroi, Belgium: 115 days left
From richardjones@optushome.com.au Sat Mar 1 07:39:02 2003
From: richardjones@optushome.com.au (Richard Jones)
Date: Sat Mar 1 07:39:02 2003
Subject: [Distutils] More documentation for setup meta-data
In-Reply-To: <3E60A0DC.7000004@lemburg.com>
References: <200302271218.46287.rjones@ekit-inc.com> <200303012151.43387.richardjones@optushome.com.au> <3E60A0DC.7000004@lemburg.com>
Message-ID: <200303012338.09555.richardjones@optushome.com.au>
On Sat, 1 Mar 2003 11:00 pm, M.-A. Lemburg wrote:
> Richard Jones wrote:
> > My argument is that the download file spec system would be quite complex
> > for the end user to work with. Well, at least I can't think of a
> > reasonable setup - but perhaps you have :)
>
> Not at all: by letting the distutils command read the spec
> file, it can make most if not all decisions automatically.
>
> In the end, the end user will just issue:
>
> python pypi.py install pyxml
>
> and the system will do the rest (talk to the PyPI server,
> fetch the download spec, identify the right download URL,
> find a usable mirror, download the prebuilt binary
> distribution and install it).
Sorry, I wasn't clear. The end user I was referring to was the package=20
maintainer. We discuss this below though...
> >>Perhaps it needs to be renamed to 'download_spec_url'.
> >
> > Hurm - we could just accept that a download url with a specific suffix =
is
> > a spec (eg. .pkgspec)? We could go as far as say that if it's an XML fi=
le
> > (ie. .xml), then it's a download spec. I'm pre-supposing XML, of course,
> > when the INI format would probably be enough. Again, I think I'd like to
> > see some more flesh on your proposal (especially the bits about making =
it
> > as simple as possible for the package maintainer) before I jump on the
> > band-wagon :)
>
> Have a look at the ActiveState PPD format (used by their PPM
> system to find the right download files):
>
> """
>
> eGenix mx Extensions for Python - Base Distribution</TITL=
E>
> <ABSTRACT>The eGenix mx Extension Series are a collection of
> Python extensions written in ANSI C and Python
> which provide a large spectrum of useful additions
> to everyday Python programming.
>
> The Base Distribution includes the Open Source subpackages
> of the series and is needed by all other add-on
> packages of the series.
>
> This software is brought to you by eGenix.com and
> distributed under the eGenix.com Public License.
> </ABSTRACT>
> <AUTHOR>Marc-Andre Lemburg (mal@egenix.com)</AUTHOR>
> <IMPLEMENTATION>
> <PYTHONCORE VERSION=3D"2.1.3" />
> <OS VALUE=3D"linux-i686" />
> <ARCHITECTURE VALUE=3D"i686-linux-thread-multi" />
> <CODEBASE
> HREF=3D"http://www.egenix.com/files/python/egenix-mx-base-2.1.0.linux-i68=
6.gz
>tar" /> </IMPLEMENTATION>
> </SOFTPKG>
> """
>
> I think we can build on that.
Hopefully by making it significantly simpler. Preferrably with no hand-edit=
ing=20
of XML. One of my goals with PyPI registration was to make the operation as=
=20
simple and transparent as possible.
Hurm. I suppose the download spec file generation could be automated at the=
=20
time the dist (either source or binary) file is generated, or perhaps using=
a=20
switch to the dist command. At a minimum, we could produce a skeleton that=
=20
the package maintainer needs to edit. Again, not necessarily XML, as that=20
requires - well, editing XML, which I see as an unreasonable barrier to=20
entry.
Richard
From mal@lemburg.com Sat Mar 1 07:56:03 2003
From: mal@lemburg.com (M.-A. Lemburg)
Date: Sat Mar 1 07:56:03 2003
Subject: [Distutils] More documentation for setup meta-data
In-Reply-To: <200303012338.09555.richardjones@optushome.com.au>
References: <200302271218.46287.rjones@ekit-inc.com> <200303012151.43387.richardjones@optushome.com.au> <3E60A0DC.7000004@lemburg.com> <200303012338.09555.richardjones@optushome.com.au>
Message-ID: <3E60AD9A.5050302@lemburg.com>
Richard Jones wrote:
> On Sat, 1 Mar 2003 11:00 pm, M.-A. Lemburg wrote:
>>>>Perhaps it needs to be renamed to 'download_spec_url'.
>>>
>>>Hurm - we could just accept that a download url with a specific suffix is
>>>a spec (eg. .pkgspec)? We could go as far as say that if it's an XML file
>>>(ie. .xml), then it's a download spec. I'm pre-supposing XML, of course,
>>>when the INI format would probably be enough. Again, I think I'd like to
>>>see some more flesh on your proposal (especially the bits about making it
>>>as simple as possible for the package maintainer) before I jump on the
>>>band-wagon :)
>>
>>Have a look at the ActiveState PPD format (used by their PPM
>>system to find the right download files):
>>
>>"""
>><SOFTPKG NAME="egenix-mx-base" VERSION="2,1,0">
>> <TITLE>eGenix mx Extensions for Python - Base Distribution
>> The eGenix mx Extension Series are a collection of
>>Python extensions written in ANSI C and Python
>>which provide a large spectrum of useful additions
>>to everyday Python programming.
>>
>>The Base Distribution includes the Open Source subpackages
>>of the series and is needed by all other add-on
>>packages of the series.
>>
>>This software is brought to you by eGenix.com and
>>distributed under the eGenix.com Public License.
>>
>> Marc-Andre Lemburg (mal@egenix.com)
>>
>>
>>
>>
>> >HREF="http://www.egenix.com/files/python/egenix-mx-base-2.1.0.linux-i686.gz
>>tar" />
>>
>>"""
>>
>>I think we can build on that.
>
>
> Hopefully by making it significantly simpler. Preferrably with no hand-editing
> of XML. One of my goals with PyPI registration was to make the operation as
> simple and transparent as possible.
>
> Hurm. I suppose the download spec file generation could be automated at the
> time the dist (either source or binary) file is generated, or perhaps using a
> switch to the dist command. At a minimum, we could produce a skeleton that
> the package maintainer needs to edit. Again, not necessarily XML, as that
> requires - well, editing XML, which I see as an unreasonable barrier to
> entry.
The above XML-snippet is generated from the meta information
given in the setup.py and the distribution build information
generated by distutils during the bdist_xxx process (note that
this has all the naming information needed including the
possible name extensions added by the package author).
There is no hand-editing of XML required :-) The specification
of alternative download URLs could be made in the setup.py file
as well (or setup.cfg for that matter), including a reference
to the mirror farm if there should ever be one.
Still to do is find a list of aspects which are needed
in order to make automatic binary download selection
robust:
* Python version string
* distutils platform string
* type of bdist/sdist
* list of external dependencies (these will most likely be lib names
which distutils can check prior to installation; needs to be
spec'ed out); alternatively, distutils could do trial-and-error
here, by calling a predefined command for checking compatibility
prior to installing the package but after having downloaded it
Anything else ?
--
Marc-Andre Lemburg
eGenix.com
Professional Python Software directly from the Source (#1, Mar 01 2003)
>>> Python/Zope Products & Consulting ... http://www.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
Python UK 2003, Oxford: 31 days left
EuroPython 2003, Charleroi, Belgium: 115 days left
From kevin@cazabon.com Sat Mar 1 09:53:01 2003
From: kevin@cazabon.com (kevin@cazabon.com)
Date: Sat Mar 1 09:53:01 2003
Subject: [Distutils] py2exe and sitecustomize.py (character set selection)
Message-ID: <000f01c2e013$1f2b0a30$310aa8c0@duallie>
Hi everyone;
I'm trying to build an .exe that uses the Latin1 character set by default by
setting: sys.setdefaultencoding("latin1") in sitecustomize.py.
The problem is that py2exe doesn't seem to be including sitecustomize.py in
a way that sets this before sys is imported. I tried using
"force-imports=sitecustomze", but to no avail.
Any suggestions? Thanks
Kevin.
From amk@amk.ca Sat Mar 1 09:57:01 2003
From: amk@amk.ca (A.M. Kuchling)
Date: Sat Mar 1 09:57:01 2003
Subject: [Distutils] More documentation for setup meta-data
In-Reply-To: <3E608604.8090202@lemburg.com>; from mal@lemburg.com on Sat, Mar 01, 2003 at 11:05:56AM +0100
References: <200302271218.46287.rjones@ekit-inc.com> <200302280851.52571.rjones@ekit-inc.com> <3E5F8CAC.8010000@lemburg.com> <200303011034.58921.rjones@ekit-inc.com> <20030228212124.B27766@nyman.amk.ca> <3E608604.8090202@lemburg.com>
Message-ID: <20030301103200.A21559@nyman.amk.ca>
On Sat, Mar 01, 2003 at 11:05:56AM +0100, M.-A. Lemburg wrote:
>Well, if you pass download_url="something" to setup() then
>you get an error saying that this is an unknown parameter.
Please file a bug on SF, including a transcript and the problematic
setup.py file. (Or post it here.) This certainly works for me
currently.
--amk (www.amk.ca)
I'm not going to sit here like a spare lemon waiting for the squeezer.
-- The Brigadier, in "The Daemons"
From amk@amk.ca Sat Mar 1 10:05:01 2003
From: amk@amk.ca (A.M. Kuchling)
Date: Sat Mar 1 10:05:01 2003
Subject: [Distutils] installing data files and headers
In-Reply-To: <3E6087BF.2000306@lemburg.com>; from mal@lemburg.com on Sat, Mar 01, 2003 at 11:13:19AM +0100
References: <1046446257.29989.79.camel@localhost.localdomain> <20030228211409.A27766@nyman.amk.ca> <3E6087BF.2000306@lemburg.com>
Message-ID: <20030301103925.A22384@nyman.amk.ca>
On Sat, Mar 01, 2003 at 11:13:19AM +0100, M.-A. Lemburg wrote:
>Why not merge package_files and package_patterns into one
>list. Then use glob.glob() to work this into a list of
>single filenames.
There's a potential problem here if I want to include the *.cfg files
in the package/ directory but not in package/example/. Maybe that
doesn't matter.
>The downside with this proposal is that you'll have to add
>MANIFEST.in rules for these files as well...
The sdist.add_defaults() method automatically includes README{.txt},
setup.py, and any referenced *.py files in the manifest; clearly if we
add additional patterns, add_defaults() should automatically include
matching files in the manifest.
--amk (www.amk.ca)
ENOBARBUS: Age cannot wither her, nor custom stale her infinite variety.
-- _Antony and Cleopatra_, II, ii
From kevin@cazabon.com Sat Mar 1 11:15:01 2003
From: kevin@cazabon.com (kevin@cazabon.com)
Date: Sat Mar 1 11:15:01 2003
Subject: [Distutils] Solution to encoding issue... sorry!
Message-ID: <002801c2e01e$a0560d70$310aa8c0@duallie>
I managed to find a solution through a combination of posts... here it is
for anyone interested:
in setup.cfg (for py2exe section):
#########################
packages=encodings
force-imports=sitecustomize
#########################
and in sitecustomize.py:
#########################
import sys, codecs
sys.setdefaultencoding("latin1")
#########################
Kevin.
From mal@lemburg.com Sat Mar 1 14:32:01 2003
From: mal@lemburg.com (M.-A. Lemburg)
Date: Sat Mar 1 14:32:01 2003
Subject: [Distutils] More documentation for setup meta-data
In-Reply-To: <20030301103200.A21559@nyman.amk.ca>
References: <200302271218.46287.rjones@ekit-inc.com> <200302280851.52571.rjones@ekit-inc.com> <3E5F8CAC.8010000@lemburg.com> <200303011034.58921.rjones@ekit-inc.com> <20030228212124.B27766@nyman.amk.ca> <3E608604.8090202@lemburg.com> <20030301103200.A21559@nyman.amk.ca>
Message-ID: <3E610A4A.3050608@lemburg.com>
A.M. Kuchling wrote:
> On Sat, Mar 01, 2003 at 11:05:56AM +0100, M.-A. Lemburg wrote:
>
>>Well, if you pass download_url="something" to setup() then
>>you get an error saying that this is an unknown parameter.
>
> Please file a bug on SF, including a transcript and the problematic
> setup.py file. (Or post it here.) This certainly works for me
> currently.
Oops. Sorry; I tried in a shell window which did not have
PYTHONPATH set to point to the CVS distutils version. If I retry
this now with properly adjusted PYTHONPATH this does work.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Software directly from the Source (#1, Mar 01 2003)
>>> Python/Zope Products & Consulting ... http://www.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
Python UK 2003, Oxford: 31 days left
EuroPython 2003, Charleroi, Belgium: 115 days left
From R.Liebscher@gmx.de Mon Mar 3 03:23:01 2003
From: R.Liebscher@gmx.de (=?iso-8859-1?Q?Ren=E9?= Liebscher)
Date: Mon Mar 3 03:23:01 2003
Subject: [Distutils] installing data files and headers
References: <1046446257.29989.79.camel@localhost.localdomain> <20030228211409.A27766@nyman.amk.ca>
Message-ID: <3E6310BD.B758157E@gmx.de>
"A.M. Kuchling" schrieb:
>
> On Fri, Feb 28, 2003 at 10:31:00AM -0500, Jeremy Hylton wrote:
> >Another problem we've been struggling with for Zope projects is that
> >distutils really only installs Python modules and extensions. It's
> >support for data files and C header files is pretty limited. We've got
>
> Good idea. We have a similar subclass for Quixote that installs *.ptl
> files, and it's a common need.
>
> >installed, so that you don't install .py~ files. One possibility is to
> >explicitly list the file extensions that constitute installable data.
> >We did that for Zope3, but the list of extensions ended up being fairly
> >long.
>
> Well, what are the options?
>
> 1) List extensions.
> 2) Explicitly list pathnames for additional files.
> 3) A MANIFEST.in-like mini-language for specifying which files should
> be installed.
> 4) Automatically add things in package directories that
> aren't obviously irrelevant (*~, *.pyc, CVS, .svn).
>
> Any other ideas?
>
> 4) probably offers too little control, and 3) might be too much, and
> adds yet another file to write. What if both 1) and 2) were
> supported, say, like this:
>
> setup(...
> package_files=['zope/app/config.xml', 'zope/app/dtd.xml'],
> package_patterns=['*.cfg'],
> )
>
In my opinion the third option is the best because it can be done
without much effort.
Look at pyxml or PYOpenGL for an example which uses one of my scripts I
wrote some time ago.
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/pyxml/xml/setupext/install_data.py?rev=1.3&content-type=text/vnd.viewcvs-markup
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/pyopengl/PyOpenGL2/setup.py?rev=1.54&content-type=text/vnd.viewcvs-markup
And its use in PyOpenGL setup.py:
...
# Overridden command classes
cmdclass = {
...
# the next line is very important
# because we use another format for
data_files
'install_data': my_install_data},
data_files = [Data_Files(
base_dir='install_lib',
copy_to = 'OpenGL',
strip_dirs = 1,
template=[
# take the whole tree
'graft OpenGL',
'global-exclude *.py',
'global-exclude Cvs/*',
'global-exclude CVS/*',
],
preserve_path=1
)],
...
It replaces the install_data command, still accepts old parameter lists,
supports
MANIFEST like specification of files and directories, and allows paths
relative to
'install_lib', ...
So this might be a good start point to replace the distutils
install_data command.
Kind regards
Rene Liebscher
From mal@lemburg.com Mon Mar 3 05:55:02 2003
From: mal@lemburg.com (M.-A. Lemburg)
Date: Mon Mar 3 05:55:02 2003
Subject: [Distutils] python-dev not installed on Unix
In-Reply-To:
References:
Message-ID: <3E633441.9030809@lemburg.com>
Juergen Hermann wrote:
> On Wed, 19 Feb 2003 11:23:07 +0100, M.-A. Lemburg wrote:
>
>>Sure. Do you have a list of common package names needed for
>>this ?
>>
>>SuSE uses "python-devel".
>
> Debian: python2.2-dev
>
> Even if we can't provide a complete list, the hint would help.
Could you cook up a path for this ?
--
Marc-Andre Lemburg
eGenix.com
Professional Python Software directly from the Source (#1, Mar 03 2003)
>>> Python/Zope Products & Consulting ... http://www.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
Python UK 2003, Oxford: 29 days left
EuroPython 2003, Charleroi, Belgium: 113 days left
From mal@lemburg.com Mon Mar 3 06:27:04 2003
From: mal@lemburg.com (M.-A. Lemburg)
Date: Mon Mar 3 06:27:04 2003
Subject: [Distutils] installing data files and headers
In-Reply-To: <20030301103925.A22384@nyman.amk.ca>
References: <1046446257.29989.79.camel@localhost.localdomain> <20030228211409.A27766@nyman.amk.ca> <3E6087BF.2000306@lemburg.com> <20030301103925.A22384@nyman.amk.ca>
Message-ID: <3E633B93.9020101@lemburg.com>
A.M. Kuchling wrote:
> On Sat, Mar 01, 2003 at 11:13:19AM +0100, M.-A. Lemburg wrote:
>
>>Why not merge package_files and package_patterns into one
>>list. Then use glob.glob() to work this into a list of
>>single filenames.
>
> There's a potential problem here if I want to include the *.cfg files
> in the package/ directory but not in package/example/. Maybe that
> doesn't matter.
Hmm, globbing 'package/*.cfg' should only include files in the
package dir.
>>The downside with this proposal is that you'll have to add
>>MANIFEST.in rules for these files as well...
>
> The sdist.add_defaults() method automatically includes README{.txt},
> setup.py, and any referenced *.py files in the manifest; clearly if we
> add additional patterns, add_defaults() should automatically include
> matching files in the manifest.
I was referring to any files that a package author adds to the
package via package_files (beyond the default ones like README);
he would have to add the same globbing patterns to MANIFEST.in
in order to have them included in the sdist.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Software directly from the Source (#1, Mar 03 2003)
>>> Python/Zope Products & Consulting ... http://www.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
Python UK 2003, Oxford: 29 days left
EuroPython 2003, Charleroi, Belgium: 113 days left
From gward@python.net Mon Mar 3 08:35:02 2003
From: gward@python.net (Greg Ward)
Date: Mon Mar 3 08:35:02 2003
Subject: [Distutils] Re: A question on Python Distutil
In-Reply-To: <200302230718.h1N7I0O16266@evelyn.kushala.com>
References: <200302230718.h1N7I0O16266@evelyn.kushala.com>
Message-ID: <20030303133408.GA4031@cthulhu.gerg.ca>
On 22 February 2003, Aki Niimura said:
> Sorry to bother you.
> I have a question on Python Distutil and so far I couldn't find
> a solution in the Internet.
Please ask Distutils questions on distutils-sig@python.org. I'll try to
answer, but I have not been heavily involved with the Distutils for
quite a while.
> My stumbling block was symbloc-link.
> In my project working directory, there are several files linked from
> another project directory (symblic link).
The distutils are mostly ignorant of symbolic links, because they're not
portable to Windows or Mac OS. So whatever "tar" does by default with
symlinks is the behaviour that you see.
>
> (ex.)
> project_A (the project to be distributed)
> setup.py (foo.py, bar.py)
> foo.py --> project_B.foo.py
> bar.py
>
> project_B (a project happened to have a useful module)
> foo.py
>
> When I run 'python setup.py sdist', a -.tar.gz was
> created but the symbolic link files remained symbolic link.
Right, because tar preserves symlinks by default.
> My questions are:
> (1) Is there any way to ask distutil to treat the file as
> a plain file not a link? (hopefully file by file)
No, not as far as I know. I can think of two kludges that might work:
* create a ZIP file instead of a tarball -- ZIP files cannot represent
symlinks, so the symlink will be followed:
./setup.py sdist --formats=zip
* write a wrapper for "tar" that forces the "-h" option (which I
think makes tar follow symlinks) into the real tar command line
> (2) What is the right approach (to your sense)
> to setup a project like this?
If this is a small, personal project that only you work on, you could
make project_A/foo.py a hardlink to ../project_B/foo.py. Hardlinks are
best avoided though -- too implicit. But I don't have any other ideas
offhand.
Greg
--
Greg Ward http://www.gerg.ca/
God is omnipotent, omniscient, and omnibenevolent
---it says so right here on the label.
From CP.Hennessy@iname.com Wed Mar 5 09:17:05 2003
From: CP.Hennessy@iname.com (CP Hennessy)
Date: Wed Mar 5 09:17:05 2003
Subject: [Distutils] Possible problem using disutils
Message-ID: <200303051417.13597.CP.Hennessy@iname.com>
Hi,
Sorry if I should be sending this to a different list, but I am not
sure if this is a problem with distutils or the package made from distutils.
I downloaded from the site http://users.skynet.be/sbi/libxml-python/
the package libxml2-python-2.4.30.win32-py2.1.exe.
However when I try to install it there is no directory listed in the
"Select python installation to use" dialog ( i.e. the second window).
I have Python installed as part of zope. And I even tried to set the
env. variable PYTHON_HOME to my python. Python is also in my
PATH.
Also I cannot manually enter a path in the "Installation Directory:"
field of the same window.
I'm trying to install this on Windows XP.
What can I do ?
Thanks
CPH
From mal@lemburg.com Wed Mar 5 11:30:02 2003
From: mal@lemburg.com (M.-A. Lemburg)
Date: Wed Mar 5 11:30:02 2003
Subject: [Distutils] Possible problem using disutils
In-Reply-To: <200303051417.13597.CP.Hennessy@iname.com>
References: <200303051417.13597.CP.Hennessy@iname.com>
Message-ID: <3E66257A.3070103@lemburg.com>
CP Hennessy wrote:
> Hi,
> Sorry if I should be sending this to a different list, but I am not
> sure if this is a problem with distutils or the package made from distutils.
>
> I downloaded from the site http://users.skynet.be/sbi/libxml-python/
> the package libxml2-python-2.4.30.win32-py2.1.exe.
> However when I try to install it there is no directory listed in the
> "Select python installation to use" dialog ( i.e. the second window).
>
> I have Python installed as part of zope. And I even tried to set the
> env. variable PYTHON_HOME to my python. Python is also in my
> PATH.
>
> Also I cannot manually enter a path in the "Installation Directory:"
> field of the same window.
> I'm trying to install this on Windows XP.
>
> What can I do ?
Zope comes with its own copy of Python which doesn't register
itself in the Windows registry. To use the above package
outside you will have to install Python using the standard
installers that are available on python.org.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Software directly from the Source (#1, Mar 05 2003)
>>> Python/Zope Products & Consulting ... http://www.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
Python UK 2003, Oxford: 27 days left
EuroPython 2003, Charleroi, Belgium: 111 days left
From CP.Hennessy@iname.com Wed Mar 5 11:47:21 2003
From: CP.Hennessy@iname.com (CP Hennessy)
Date: Wed Mar 5 11:47:21 2003
Subject: [Distutils] Possible problem using disutils
In-Reply-To: <3E66257A.3070103@lemburg.com>
References: <200303051417.13597.CP.Hennessy@iname.com> <3E66257A.3070103@lemburg.com>
Message-ID: <200303051647.41877.CP.Hennessy@iname.com>
Hi,
On Wednesday 05 March 2003 16:27, M.-A. Lemburg wrote:
> Zope comes with its own copy of Python which doesn't register
> itself in the Windows registry. To use the above package
Ah!
> outside you will have to install Python using the standard
> installers that are available on python.org.
But will this then mean that when I install python as you suggest the
software from the package I want to install will only work with this python
or will I be able to get it to work with the python from Zope ?
Thanks
CPH
From mal@lemburg.com Wed Mar 5 12:55:08 2003
From: mal@lemburg.com (M.-A. Lemburg)
Date: Wed Mar 5 12:55:08 2003
Subject: [Distutils] Possible problem using disutils
In-Reply-To: <200303051647.41877.CP.Hennessy@iname.com>
References: <200303051417.13597.CP.Hennessy@iname.com> <3E66257A.3070103@lemburg.com> <200303051647.41877.CP.Hennessy@iname.com>
Message-ID: <3E66396B.1000402@lemburg.com>
CP Hennessy wrote:
> Hi,
>
> On Wednesday 05 March 2003 16:27, M.-A. Lemburg wrote:
>
>>Zope comes with its own copy of Python which doesn't register
>>itself in the Windows registry. To use the above package
>
> Ah!
>
>
>>outside you will have to install Python using the standard
>>installers that are available on python.org.
>
> But will this then mean that when I install python as you suggest the
> software from the package I want to install will only work with this python
> or will I be able to get it to work with the python from Zope ?
It will likely not work from within Zope.
Please ask on the Zope mailing lists on how to install packages
for use within Zope. It would also be wise to complain about Zope
not registering the Python version on Windows :-) (because that
would make likfe a lot easier)
--
Marc-Andre Lemburg
eGenix.com
Professional Python Software directly from the Source (#1, Mar 05 2003)
>>> Python/Zope Products & Consulting ... http://www.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
Python UK 2003, Oxford: 27 days left
EuroPython 2003, Charleroi, Belgium: 111 days left
From CP.Hennessy@iname.com Wed Mar 5 13:06:01 2003
From: CP.Hennessy@iname.com (CP Hennessy)
Date: Wed Mar 5 13:06:01 2003
Subject: [Distutils] Possible problem using disutils
In-Reply-To: <3E66396B.1000402@lemburg.com>
References: <200303051417.13597.CP.Hennessy@iname.com> <200303051647.41877.CP.Hennessy@iname.com> <3E66396B.1000402@lemburg.com>
Message-ID: <200303051806.21035.CP.Hennessy@iname.com>
On Wednesday 05 March 2003 17:52, M.-A. Lemburg wrote:
> CP Hennessy wrote:
> > Hi,
> >
> > On Wednesday 05 March 2003 16:27, M.-A. Lemburg wrote:
> >>Zope comes with its own copy of Python which doesn't register
> >>itself in the Windows registry. To use the above package
> >
> > Ah!
> >
> >>outside you will have to install Python using the standard
> >>installers that are available on python.org.
> >
> > But will this then mean that when I install python as you suggest the
> > software from the package I want to install will only work with this
> > python or will I be able to get it to work with the python from Zope ?
>
> It will likely not work from within Zope.
>
> Please ask on the Zope mailing lists on how to install packages
> for use within Zope. It would also be wise to complain about Zope
> not registering the Python version on Windows :-) (because that
> would make likfe a lot easier)
I better make it clear that Pyton and Zope came in a CMS package called Plone.
I'll ask the Plone guys.
Thanks for your help.
CPH
From fredrik@pythonware.com Wed Mar 5 13:31:59 2003
From: fredrik@pythonware.com (Fredrik Lundh)
Date: Wed Mar 5 13:31:59 2003
Subject: [Distutils] Re: Possible problem using disutils
References: <200303051417.13597.CP.Hennessy@iname.com>
Message-ID:
CP Hennessy wrote:
> Sorry if I should be sending this to a different list, but I am not
> sure if this is a problem with distutils or the package made from distutils.
>
> I downloaded from the site http://users.skynet.be/sbi/libxml-python/
> the package libxml2-python-2.4.30.win32-py2.1.exe.
> However when I try to install it there is no directory listed in the
> "Select python installation to use" dialog ( i.e. the second window).
if zope doesn't bother to register the python interpreter, there's
no way for distutils to locate it.
more info (and a workaround) here:
http://effbot.org/zone/python-register.htm
From webmaster@pferdemarkt.ws Thu Mar 6 09:01:39 2003
From: webmaster@pferdemarkt.ws (webmaster@pferdemarkt.ws)
Date: Thu Mar 6 09:01:39 2003
Subject: [Distutils] Pferdemarkt.ws informiert! Newsletter 03/2003 http://www.pferdemarkt.ws
Message-ID: <200303061400.GAA20954@eagle.he.net>
http://www.pferdemarkt.ws
Wir sind in 2003 erfolgreich in des neue \"Pferdejahr 2003 gestartet.
Für den schnellen Erfolg unseres Marktes möchten wir uns bei Ihnen bedanken.
Heute am 06.03.2003 sind wir gut 2 Monate Online!
Täglich wächst unsere Datenbank um 30 Neue Angebote.
Stellen auch Sie als Privatperson Ihre zu verkaufenden Pferde direkt und
vollkommen Kostenlos ins Internet.
Zur besseren Sichtbarmachung Ihrer Angebote können SIe bis zu ein Bild zu Ihrer
Pferdeanzeige kostenlos einstellen!
Wollen Sie direkt auf die erste Seite, dann können wir Ihnen unser Bonussystem empfehlen.
klicken Sie hier: http://www.pferdemarkt.ws/bestellung.html
Ihr http://Pferdemarkt.ws Team
Klicken Sie hier um sich direkt einzuloggen http://www.Pferdemarkt.ws
Kostenlos Anbieten, Kostenlos Suchen! Direkt von Privat zu Privat!
Haben Sie noch Fragen mailto: webmaster@pferdemarkt.ws
From exarkun@intarweb.us Sat Mar 8 20:59:01 2003
From: exarkun@intarweb.us (Jp Calderone)
Date: Sat Mar 8 20:59:01 2003
Subject: [Distutils] CVS distutils & bdist_wininst
Message-ID: <20030309015733.GA10217@meson.dyndns.org>
--LQksG6bCIzRHxTLp
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Hello the list,
CVS HEAD of distutils doesn't currently seem to install misc/wininst.exe
when "./setup.py install" is run. This causes bdist_wininst to fail with
error: /usr/local/lib/python2.2/site-packages/distutils/command/wininst.exe:
No such file or directory
(It is easily rectified by copying the file into place manually.)
I'm not sure if anyone was aware of this, or if it's even appropriate to
report CVS bugs to the list. Apologies if this is the wrong forum.
Jp
--=20
"There is no reason for any individual to have a computer in their
home."
-- Ken Olson, President of DEC, World Future Society
Convention, 1977
--=20
up 5 days, 17:59, 10 users, load average: 1.17, 0.91, 0.47
--LQksG6bCIzRHxTLp
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.0 (GNU/Linux)
iD8DBQE+ap+NedcO2BJA+4YRArK7AJ9Nx+T+H2CC+JSX4M48dA56fgQ5UwCeIdwy
AUJmaAWDrVAVgiAnt31BLH4=
=Y+Kw
-----END PGP SIGNATURE-----
--LQksG6bCIzRHxTLp--
From Harald.Meland@usit.uio.no Thu Mar 13 12:08:03 2003
From: Harald.Meland@usit.uio.no (Harald Meland)
Date: Thu Mar 13 12:08:03 2003
Subject: [Distutils] Installing scripts to multiple directories
Message-ID:
Hi,
I'm trying to figure out how I can make distutils support installation
of scripts to more than one directory, e.g. both /bin/ and
/sbin/.
I've found an open bug[1] on this in the Python project on
SourceForge, but it's now over a year since the person that bug is
assigned to said that he would "look at this".
I started by looking through the documentation, but could not find any
info on how to extend distutils. Hence, I had a look at how distutils
is currently implemented, but I'm still not sure how one is meant to
*properly* extend the "install*" feature set.
Have anyone done this particular extension already? If not, are there
any guidelines on how such an extension ought to be done?
[1] Bug id 452144, viewable at
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=452144&group_id=5470
--
Harald
From mwh@python.net Thu Mar 13 12:15:02 2003
From: mwh@python.net (Michael Hudson)
Date: Thu Mar 13 12:15:02 2003
Subject: [Distutils] Installing scripts to multiple directories
In-Reply-To: (Harald Meland's message of
"Thu, 13 Mar 2003 18:06:54 +0100")
References:
Message-ID: <2msmtrxk7w.fsf@starship.python.net>
Harald Meland writes:
> Hi,
>
> I'm trying to figure out how I can make distutils support installation
> of scripts to more than one directory, e.g. both /bin/ and
> /sbin/.
>
> I've found an open bug[1] on this in the Python project on
> SourceForge, but it's now over a year since the person that bug is
> assigned to said that he would "look at this".
That would have been me. I've unassigned it from myself, which I
guess isn't progress... but is realistic, I'm afraid.
> I started by looking through the documentation, but could not find any
> info on how to extend distutils. Hence, I had a look at how distutils
> is currently implemented, but I'm still not sure how one is meant to
> *properly* extend the "install*" feature set.
I think that any way that works is more or less the proper way.
The distutils are a thing of wonder, but the code isn't the easiest to
understand in the world.
Cheers,
M.
--
If trees could scream, would we be so cavalier about cutting them
down? We might, if they screamed all the time, for no good reason.
-- Jack Handey
From Harald.Meland@usit.uio.no Thu Mar 13 17:30:07 2003
From: Harald.Meland@usit.uio.no (Harald Meland)
Date: Thu Mar 13 17:30:07 2003
Subject: [Distutils] Installing scripts to multiple directories
In-Reply-To: <2msmtrxk7w.fsf@starship.python.net> (Michael Hudson's message
of "Thu, 13 Mar 2003 17:14:11 +0000")
References:
<2msmtrxk7w.fsf@starship.python.net>
Message-ID:
[Michael Hudson]
> Harald Meland writes:
>
>> Hi,
>>
>> I'm trying to figure out how I can make distutils support installation
>> of scripts to more than one directory, e.g. both /bin/ and
>> /sbin/.
>>
>> I've found an open bug[1] on this in the Python project on
>> SourceForge, but it's now over a year since the person that bug is
>> assigned to said that he would "look at this".
>
> That would have been me. I've unassigned it from myself, which I
> guess isn't progress... but is realistic, I'm afraid.
OK.
>> I started by looking through the documentation, but could not find any
>> info on how to extend distutils. Hence, I had a look at how distutils
>> is currently implemented, but I'm still not sure how one is meant to
>> *properly* extend the "install*" feature set.
>
> I think that any way that works is more or less the proper way.
Hmmm... I think I might be able to pull off something that will work
with the code as it stands today. However, it will probably be rather
fragile with respect to any changes done to any of the involved
distutils commands (as my current plan is to have my extensions
subclass these).
However, I'm wondering if the functionality I'm after ought to be part
of vanilla distutils. If there's interest in making it an official
part of distutils, it would maybe be better to actually rewrite the
involved parts of distutils instead of trying to subclass them (in
fragile ways).
Any thoughts on what implementation past I should choose?
> The distutils are a thing of wonder, but the code isn't the easiest to
> understand in the world.
True. :-)
--
Harald
From mal@lemburg.com Fri Mar 14 03:34:02 2003
From: mal@lemburg.com (M.-A. Lemburg)
Date: Fri Mar 14 03:34:02 2003
Subject: [Distutils] Installing scripts to multiple directories
In-Reply-To:
References: <2msmtrxk7w.fsf@starship.python.net>
Message-ID: <3E7193A9.8010803@lemburg.com>
Harald Meland wrote:
> [Michael Hudson]
>>Harald Meland writes:
>>>Hi,
>>>
>>>I'm trying to figure out how I can make distutils support installation
>>>of scripts to more than one directory, e.g. both /bin/ and
>>>/sbin/.
>
> Hmmm... I think I might be able to pull off something that will work
> with the code as it stands today. However, it will probably be rather
> fragile with respect to any changes done to any of the involved
> distutils commands (as my current plan is to have my extensions
> subclass these).
Subclassing is probably the right thing to do here. The easiest
way to do this is by writing you own command and then let that
command replace the standard install_scripts command.
> However, I'm wondering if the functionality I'm after ought to be part
> of vanilla distutils. If there's interest in making it an official
> part of distutils, it would maybe be better to actually rewrite the
> involved parts of distutils instead of trying to subclass them (in
> fragile ways).
You'd most probably break lots of existing code out there
which already does this.
IMHO, the right path to choose would be to factor out some parts
which then provide better and cleaner ways to hook into via
subclassing. Some methods in distutils are rather convoluted (e.g.
various .run() methods and adding something to the middle of these
methods usually turns out to be a copy & insert procedure which is
not ideal (and usually breaks every now and then if you upgrade
distutils).
--
Marc-Andre Lemburg
eGenix.com
Professional Python Software directly from the Source (#1, Mar 14 2003)
>>> Python/Zope Products & Consulting ... http://www.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
Python UK 2003, Oxford: 18 days left
EuroPython 2003, Charleroi, Belgium: 102 days left
From hoel@gl-group.com Tue Mar 18 10:16:02 2003
From: hoel@gl-group.com (=?iso-8859-15?Q?Berthold_H=F6llmann?=)
Date: Tue Mar 18 10:16:02 2003
Subject: [Distutils] Mixing pure python and extension module and multi platform
Message-ID:
Hello,
We have a quite large project of some quite stable extension modules
and lots of frequently changing python modules. The whole thing works
under Solaris and Linux. Both operating systems are accessing the same
file tree using NFS.
My problem now is that setup on a mixed module installes everything
into the system dependent branch of the install directories. It would
be nice if there is a simple customizing of the setup procedure to
make setup install the extension modules into the system depending
branch and the python modules into the system independent branch. Of
course I can issue two "setup" commands in the setup.py, but that
produces ugly results when it comes to generating binary installation
packages.
Regards
Berthold
--=20
Dipl.-Ing. Berthold H=F6llmann __ Address:
hoel@GL-Group.com G / \ L Germanischer Lloyd
phone: +49-40-36149-7374 -+----+- Vorsetzen 32/35 P.O.Box 111606
fax : +49-40-36149-7320 \__/ D-20459 Hamburg D-20416 Hamburg
=20
=20
=20
=20
****************************************************
=20
=20
Beachten Sie: Wir moechten Sie informieren, dass die E-Mail-Adresse des =
Germanischen Lloyd sowie unsere Web-Adresse mit Wirkung vom 1. Maerz =
2003 auf den Namen gl-group.com umgestellt wurde.
=20
=20
Dies bedeutet, dass die bisherige Adresse Kurzzeichen@germanlloyd.org =
durch die neue Adresse Kurzzeichen@gl-group.com ersetzt wird. Die =
Homepage des GL ist kuenftig ueber die Adresse 'http://www.gl-group.com' =
aufrufbar. Die bisher verwendeten Adressen bleiben f=FCr eine =
Uebergangsfrist erreichbar.
=20
=20
****************************************************=20
=20
Please notice: We would like to inform you that the e-mail address of =
Germanischer Lloyd as well as our internet address had been changed to =
gl-group.com with effect from 1st March 2003.
=20
=20
This means that the previous address shortmark@germanlloyd.org will be =
replaced by shortmark@gl-group.com. From now on the GL homepage can be =
accessed at the address 'http://www.gl-group.com'. The old addresses =
remain valid for a transitional period.
=20
=20
=20
****************************************************
=20
=20
=20
=20
This e-mail contains confidential information for the exclusive =
attention of the intended addressee. Any access of third parties to this =
e-mail is unauthorised. Any use of this e-mail by unintended recipients =
such as copying, distribution, disclosure etc. is prohibited and may be =
unlawful. When addressed to our clients the content of this e-mail is =
subject to the General Terms and Conditions of GL's Group of Companies =
applicable at the date of this e-mail. =20
=20
GL's Group of Companies does not warrant and/or guarantee that this =
message at the moment of receipt is authentic, correct and its =
communication free of errors, interruption etc.=20
=20
=20
From jh@web.de Tue Mar 18 19:36:07 2003
From: jh@web.de (Juergen Hermann)
Date: Tue Mar 18 19:36:07 2003
Subject: [Distutils] Mixing pure python and extension module and multi platform
In-Reply-To:
Message-ID:
On=2018=20Mar=202003=2016:15:18=20+0100,=20Berthold=20H=F6llmann=20wrote:
>My=20problem=20now=20is=20that=20setup=20on=20a=20mixed=20module=20instal=
les=20everything
>into=20the=20system=20dependent=20branch=20of=20the=20install=20directori=
es.
Errmmmm,=20setup.py=20install=20--help
Options=20for=20'install'=20command:
...
=20=20--install-base=20=20=20=20=20=20base=20installation=20directory=20(i=
nstead=20of=20--prefix=20or=20--
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20home)
=20=20--install-platbase=20=20base=20installation=20directory=20for=20plat=
form-specific=20files
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20(instead=
=20of=20--exec-prefix=20or=20--home)
=20=20--install-purelib=20=20=20installation=20directory=20for=20pure=20Py=
thon=20module
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20distribu=
tions
=20=20--install-platlib=20=20=20installation=20directory=20for=20non-pure=20=
module=20distributions
Ciao,=20J=FCrgen
From hoel@gl-group.com Wed Mar 19 04:57:02 2003
From: hoel@gl-group.com (=?iso-8859-15?Q?Berthold_H=F6llmann?=)
Date: Wed Mar 19 04:57:02 2003
Subject: [Distutils] Re: Mixing pure python and extension module and multi platform
In-Reply-To:
References:
Message-ID:
"Juergen Hermann" writes:
> On 18 Mar 2003 16:15:18 +0100, Berthold H=F6llmann wrote:
> >My problem now is that setup on a mixed module installes everything
> >into the system dependent branch of the install directories.
>=20
> Errmmmm, setup.py install --help
>=20
> Options for 'install' command:
> ...
> --install-base base installation directory (instead of --prefix =
or --
> home)
> --install-platbase base installation directory for =
platform-specific files
> (instead of --exec-prefix or --home)
> --install-purelib installation directory for pure Python module
> distributions
> --install-platlib installation directory for non-pure module =
distributions
Errmmm, what I am looking for is a way to have, installing mixed
modules, the extension modules installed in the --install-platlib tree
and the pure python modules installed in the --install-purelib
path. Now when you install mixed moudules everything gets installed
into the --install-platlib tree, even the pure python modules.
Regards,
Berthold
--=20
Dipl.-Ing. Berthold H=F6llmann __ Address:
hoel@GL-Group.com G / \ L Germanischer Lloyd
phone: +49-40-36149-7374 -+----+- Vorsetzen 32/35 P.O.Box 111606
fax : +49-40-36149-7320 \__/ D-20459 Hamburg D-20416 Hamburg
=20
=20
=20
=20
****************************************************
=20
=20
Beachten Sie: Wir moechten Sie informieren, dass die E-Mail-Adresse des =
Germanischen Lloyd sowie unsere Web-Adresse mit Wirkung vom 1. Maerz =
2003 auf den Namen gl-group.com umgestellt wurde.
=20
=20
Dies bedeutet, dass die bisherige Adresse Kurzzeichen@germanlloyd.org =
durch die neue Adresse Kurzzeichen@gl-group.com ersetzt wird. Die =
Homepage des GL ist kuenftig ueber die Adresse 'http://www.gl-group.com' =
aufrufbar. Die bisher verwendeten Adressen bleiben f=FCr eine =
Uebergangsfrist erreichbar.
=20
=20
****************************************************=20
=20
Please notice: We would like to inform you that the e-mail address of =
Germanischer Lloyd as well as our internet address had been changed to =
gl-group.com with effect from 1st March 2003.
=20
=20
This means that the previous address shortmark@germanlloyd.org will be =
replaced by shortmark@gl-group.com. From now on the GL homepage can be =
accessed at the address 'http://www.gl-group.com'. The old addresses =
remain valid for a transitional period.
=20
=20
=20
****************************************************
=20
=20
=20
=20
This e-mail contains confidential information for the exclusive =
attention of the intended addressee. Any access of third parties to this =
e-mail is unauthorised. Any use of this e-mail by unintended recipients =
such as copying, distribution, disclosure etc. is prohibited and may be =
unlawful. When addressed to our clients the content of this e-mail is =
subject to the General Terms and Conditions of GL's Group of Companies =
applicable at the date of this e-mail. =20
=20
GL's Group of Companies does not warrant and/or guarantee that this =
message at the moment of receipt is authentic, correct and its =
communication free of errors, interruption etc.=20
=20
=20
From mal@lemburg.com Wed Mar 19 05:17:11 2003
From: mal@lemburg.com (M.-A. Lemburg)
Date: Wed Mar 19 05:17:11 2003
Subject: [Distutils] Re: Mixing pure python and extension module and multi
platform
In-Reply-To:
References:
Message-ID: <3E784350.1030103@lemburg.com>
Berthold H=F6llmann wrote:
> "Juergen Hermann" writes:
>=20
>>On 18 Mar 2003 16:15:18 +0100, Berthold H=F6llmann wrote:
>>
>>>My problem now is that setup on a mixed module installes everything
>>>into the system dependent branch of the install directories.
>>
>>Errmmmm, setup.py install --help
>>
>>Options for 'install' command:
>>...
>> --install-base base installation directory (instead of --prefix =
or --
>> home)
>> --install-platbase base installation directory for platform-specific=
files
>> (instead of --exec-prefix or --home)
>> --install-purelib installation directory for pure Python module
>> distributions
>> --install-platlib installation directory for non-pure module distri=
butions
>=20
>=20
> Errmmm, what I am looking for is a way to have, installing mixed
> modules, the extension modules installed in the --install-platlib tree
> and the pure python modules installed in the --install-purelib
> path. Now when you install mixed moudules everything gets installed
> into the --install-platlib tree, even the pure python modules.
If you are using packages, that's the only way it works (you can't
have two parallel package structures with the same base name in
Python). If you are distributing the files as top-level files,
then this looks like a bug.
--=20
Marc-Andre Lemburg
eGenix.com
Professional Python Software directly from the Source (#1, Mar 19 2003)
>>> Python/Zope Products & Consulting ... http://www.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
Python UK 2003, Oxford: 13 days left
EuroPython 2003, Charleroi, Belgium: 97 days left
From hoel@gl-group.com Wed Mar 19 05:46:35 2003
From: hoel@gl-group.com (=?iso-8859-15?Q?Berthold_H=F6llmann?=)
Date: Wed Mar 19 05:46:35 2003
Subject: [Distutils] Re: Mixing pure python and extension module and multi platform
In-Reply-To: <3E784350.1030103@lemburg.com>
References: <3E784350.1030103@lemburg.com>
Message-ID:
"M.-A. Lemburg" writes:
> Berthold H=F6llmann wrote:
> > "Juergen Hermann" writes:
> >
> >>On 18 Mar 2003 16:15:18 +0100, Berthold H=F6llmann wrote:
> >>
> >>>My problem now is that setup on a mixed module installes everything
> >>>into the system dependent branch of the install directories.
> >>
> >>Errmmmm, setup.py install --help
> >>
> >>Options for 'install' command:
> >>...
> >> --install-base base installation directory (instead of =
--prefix or --
> >> home)
> >> --install-platbase base installation directory for =
platform-specific files
> >> (instead of --exec-prefix or --home)
> >> --install-purelib installation directory for pure Python module
> >> distributions
> >> --install-platlib installation directory for non-pure module =
distributions
> > Errmmm, what I am looking for is a way to have, installing mixed
> > modules, the extension modules installed in the --install-platlib =
tree
> > and the pure python modules installed in the --install-purelib
> > path. Now when you install mixed moudules everything gets installed
> > into the --install-platlib tree, even the pure python modules.
>=20
> If you are using packages, that's the only way it works (you can't
> have two parallel package structures with the same base name in
> Python). If you are distributing the files as top-level files,
> then this looks like a bug.
So it is, I guess a bug. I build a small example:
>cat spam.c=20
#include
static PyObject *
spam_system(self, args)
PyObject *self;
PyObject *args;
{
char *command;
int sts;
if (!PyArg_ParseTuple(args, "s", &command))
return NULL;
sts =3D system(command);
return Py_BuildValue("i", sts);
}
static PyObject *SpamError;
static PyMethodDef SpamMethods[] =3D {
{"system", spam_system, METH_VARARGS,
"Execute a shell command."},
{NULL, NULL, 0, NULL} /* Sentinel */
};
void
initspam(void)
{
PyObject *m, *d;
m =3D Py_InitModule("spam", SpamMethods);
d =3D PyModule_GetDict(m);
SpamError =3D PyErr_NewException("spam.error", NULL, NULL);
PyDict_SetItemString(d, "error", SpamError);
}
>cat pork.py=20
import spam as _spam
def spam():
return _spam.system("ls -l")
>cat setup.py=20
from distutils.core import setup,Extension
setup (name =3D "pork.spam",
version =3D "0.0.0",
description =3D "just a test",
author =3D 'Berthold H=F6llmann',
author_email =3D "hoel@GL-Group.com",
ext_modules =3D [Extension('spam', ['spam.c'])],
package_dir =3D {'pork': '.'},
py_modules =3D ['pork.pork'],
)
>touch __init__.py
>python setup.py build
...
>python setup.py -n install
Adding parser accelerators ...
Done.
running install
running build
running build_py
not copying ./__init__.py (output up-to-date)
not copying ./pork.py (output up-to-date)
running build_ext
skipping 'spam' extension (up-to-date)
running install_lib
copying build/lib.linux-i686-2.2/pork/pork.py -> =
/usr/local/fitools/sandbox/linux/lib/python2.2/site-packages/pork
copying build/lib.linux-i686-2.2/pork/__init__.py -> =
/usr/local/fitools/sandbox/linux/lib/python2.2/site-packages/pork
copying build/lib.linux-i686-2.2/spam.so -> =
/usr/local/fitools/sandbox/linux/lib/python2.2/site-packages
error: file =
'/usr/local/fitools/sandbox/linux/lib/python2.2/site-packages/pork/pork.p=
y' does not exist
[16957 refs]
>python -c "import distutils.sysconfig as d;print =
d.get_python_lib();print d.get_python_lib(True)"
Adding parser accelerators ...
Done.
/usr/local/fitools/sandbox/lib/python2.2/site-packages
/usr/local/fitools/sandbox/linux/lib/python2.2/site-packages
[5792 refs]
In my understanding pork.py sould have gone to
/usr/local/fitools/sandbox/lib/python2.2/site-packages/pork instead of
/usr/local/fitools/sandbox/linux/lib/python2.2/site-packages/pork
(same of course for __init__.py).
Regards
Berthold
--=20
Dipl.-Ing. Berthold H=F6llmann __ Address:
hoel@GL-Group.com G / \ L Germanischer Lloyd
phone: +49-40-36149-7374 -+----+- Vorsetzen 32/35 P.O.Box 111606
fax : +49-40-36149-7320 \__/ D-20459 Hamburg D-20416 Hamburg
=20
=20
=20
=20
****************************************************
=20
=20
Beachten Sie: Wir moechten Sie informieren, dass die E-Mail-Adresse des =
Germanischen Lloyd sowie unsere Web-Adresse mit Wirkung vom 1. Maerz =
2003 auf den Namen gl-group.com umgestellt wurde.
=20
=20
Dies bedeutet, dass die bisherige Adresse Kurzzeichen@germanlloyd.org =
durch die neue Adresse Kurzzeichen@gl-group.com ersetzt wird. Die =
Homepage des GL ist kuenftig ueber die Adresse 'http://www.gl-group.com' =
aufrufbar. Die bisher verwendeten Adressen bleiben f=FCr eine =
Uebergangsfrist erreichbar.
=20
=20
****************************************************=20
=20
Please notice: We would like to inform you that the e-mail address of =
Germanischer Lloyd as well as our internet address had been changed to =
gl-group.com with effect from 1st March 2003.
=20
=20
This means that the previous address shortmark@germanlloyd.org will be =
replaced by shortmark@gl-group.com. From now on the GL homepage can be =
accessed at the address 'http://www.gl-group.com'. The old addresses =
remain valid for a transitional period.
=20
=20
=20
****************************************************
=20
=20
=20
=20
This e-mail contains confidential information for the exclusive =
attention of the intended addressee. Any access of third parties to this =
e-mail is unauthorised. Any use of this e-mail by unintended recipients =
such as copying, distribution, disclosure etc. is prohibited and may be =
unlawful. When addressed to our clients the content of this e-mail is =
subject to the General Terms and Conditions of GL's Group of Companies =
applicable at the date of this e-mail. =20
=20
GL's Group of Companies does not warrant and/or guarantee that this =
message at the moment of receipt is authentic, correct and its =
communication free of errors, interruption etc.=20
=20
=20
From mal@lemburg.com Wed Mar 19 06:07:01 2003
From: mal@lemburg.com (M.-A. Lemburg)
Date: Wed Mar 19 06:07:01 2003
Subject: [Distutils] Re: Mixing pure python and extension module and multi platform
In-Reply-To:
References: <3E784350.1030103@lemburg.com>
Message-ID: <3E784F1C.10902@lemburg.com>
Berthold H=F6llmann wrote:
> "M.-A. Lemburg" writes:
>>If you are using packages, that's the only way it works (you can't
>>have two parallel package structures with the same base name in
>>Python). If you are distributing the files as top-level files,
>>then this looks like a bug.
>=20
> So it is, I guess a bug. I build a small example:
I don't think so...
> setup (name =3D "pork.spam",
> version =3D "0.0.0",
> description =3D "just a test",
> author =3D 'Berthold H=F6llmann',
> author_email =3D "hoel@GL-Group.com",
> ext_modules =3D [Extension('spam', ['spam.c'])],
> package_dir =3D {'pork': '.'},
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> py_modules =3D ['pork.pork'],
> )
--=20
Marc-Andre Lemburg
eGenix.com
Professional Python Software directly from the Source (#1, Mar 19 2003)
>>> Python/Zope Products & Consulting ... http://www.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
Python UK 2003, Oxford: 13 days left
EuroPython 2003, Charleroi, Belgium: 97 days left
From hoel@gl-group.com Wed Mar 19 06:16:38 2003
From: hoel@gl-group.com (=?iso-8859-15?Q?Berthold_H=F6llmann?=)
Date: Wed Mar 19 06:16:38 2003
Subject: [Distutils] Re: Mixing pure python and extension module and multi platform
In-Reply-To: <3E784F1C.10902@lemburg.com>
References: <3E784350.1030103@lemburg.com><3E784F1C.10902@lemburg.com>
Message-ID:
"M.-A. Lemburg" writes:
> Berthold H=F6llmann wrote:
> > "M.-A. Lemburg" writes:
> >>If you are using packages, that's the only way it works (you can't
> >>have two parallel package structures with the same base name in
> >>Python). If you are distributing the files as top-level files,
> >>then this looks like a bug.
> > So it is, I guess a bug. I build a small example:
>=20
> I don't think so...
>=20
> > setup (name =3D "pork.spam",
> > version =3D "0.0.0",
> > description =3D "just a test",
> > author =3D 'Berthold H=F6llmann',
> > author_email =3D "hoel@GL-Group.com",
> > ext_modules =3D [Extension('spam', ['spam.c'])],
> > package_dir =3D {'pork': '.'},
>=20
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>=20
> > py_modules =3D ['pork.pork'],
> > )
sorry, of course, but, I moved pork.py and __init__.py to the new
generated pork subdirectory, removed the "package_dir" line and
>python setup.py -n install
Adding parser accelerators ...
Done.
running install
running build
running build_py
copying pork/__init__.py -> build/lib.linux-i686-2.2/pork
not copying pork/pork.py (output up-to-date)
running build_ext
skipping 'spam' extension (up-to-date)
running install_lib
copying build/lib.linux-i686-2.2/pork/pork.py -> =
/usr/local/fitools/sandbox/linux/lib/python2.2/site-packages/pork
copying build/lib.linux-i686-2.2/spam.so -> =
/usr/local/fitools/sandbox/linux/lib/python2.2/site-packages
error: file =
'/usr/local/fitools/sandbox/linux/lib/python2.2/site-packages/pork/pork.p=
y' does not exist
[16946 refs]
Do you accept this as an error?
Regards
Berthold
--=20
Dipl.-Ing. Berthold H=F6llmann __ Address:
hoel@GL-Group.com G / \ L Germanischer Lloyd
phone: +49-40-36149-7374 -+----+- Vorsetzen 32/35 P.O.Box 111606
fax : +49-40-36149-7320 \__/ D-20459 Hamburg D-20416 Hamburg
=20
=20
=20
=20
****************************************************
=20
=20
Beachten Sie: Wir moechten Sie informieren, dass die E-Mail-Adresse des =
Germanischen Lloyd sowie unsere Web-Adresse mit Wirkung vom 1. Maerz =
2003 auf den Namen gl-group.com umgestellt wurde.
=20
=20
Dies bedeutet, dass die bisherige Adresse Kurzzeichen@germanlloyd.org =
durch die neue Adresse Kurzzeichen@gl-group.com ersetzt wird. Die =
Homepage des GL ist kuenftig ueber die Adresse 'http://www.gl-group.com' =
aufrufbar. Die bisher verwendeten Adressen bleiben f=FCr eine =
Uebergangsfrist erreichbar.
=20
=20
****************************************************=20
=20
Please notice: We would like to inform you that the e-mail address of =
Germanischer Lloyd as well as our internet address had been changed to =
gl-group.com with effect from 1st March 2003.
=20
=20
This means that the previous address shortmark@germanlloyd.org will be =
replaced by shortmark@gl-group.com. From now on the GL homepage can be =
accessed at the address 'http://www.gl-group.com'. The old addresses =
remain valid for a transitional period.
=20
=20
=20
****************************************************
=20
=20
=20
=20
This e-mail contains confidential information for the exclusive =
attention of the intended addressee. Any access of third parties to this =
e-mail is unauthorised. Any use of this e-mail by unintended recipients =
such as copying, distribution, disclosure etc. is prohibited and may be =
unlawful. When addressed to our clients the content of this e-mail is =
subject to the General Terms and Conditions of GL's Group of Companies =
applicable at the date of this e-mail. =20
=20
GL's Group of Companies does not warrant and/or guarantee that this =
message at the moment of receipt is authentic, correct and its =
communication free of errors, interruption etc.=20
=20
=20
From mal@lemburg.com Wed Mar 19 08:04:05 2003
From: mal@lemburg.com (M.-A. Lemburg)
Date: Wed Mar 19 08:04:05 2003
Subject: [Distutils] Re: Mixing pure python and extension module and multi
platform
In-Reply-To:
References: <3E784350.1030103@lemburg.com><3E784F1C.10902@lemburg.com>
Message-ID: <3E786A99.4070804@lemburg.com>
Berthold H=F6llmann wrote:
> "M.-A. Lemburg" writes:
>=20
>=20
>>Berthold H=F6llmann wrote:
>>
>>>"M.-A. Lemburg" writes:
>>>
>>>>If you are using packages, that's the only way it works (you can't
>>>>have two parallel package structures with the same base name in
>>>>Python). If you are distributing the files as top-level files,
>>>>then this looks like a bug.
>>>
>>>So it is, I guess a bug. I build a small example:
>>
>>I don't think so...
>>
>>
>>>setup (name =3D "pork.spam",
>>> version =3D "0.0.0",
>>> description =3D "just a test",
>>> author =3D 'Berthold H=F6llmann',
>>> author_email =3D "hoel@GL-Group.com",
>>> ext_modules =3D [Extension('spam', ['spam.c'])],
>>> package_dir =3D {'pork': '.'},
>>
>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>
>>
>>> py_modules =3D ['pork.pork'],
>>>)
>=20
>=20
> sorry, of course, but, I moved pork.py and __init__.py to the new
> generated pork subdirectory, removed the "package_dir" line and
You should also rename the py_modules entry to 'pork'.
>>python setup.py -n install
Uhm, where did you tell distutils to install in two different
directories for platform dependent and independent files ?
> Adding parser accelerators ...
> Done.
> running install
> running build
> running build_py
> copying pork/__init__.py -> build/lib.linux-i686-2.2/pork
> not copying pork/pork.py (output up-to-date)
> running build_ext
> skipping 'spam' extension (up-to-date)
> running install_lib
> copying build/lib.linux-i686-2.2/pork/pork.py -> /usr/local/fitools/san=
dbox/linux/lib/python2.2/site-packages/pork
> copying build/lib.linux-i686-2.2/spam.so -> /usr/local/fitools/sandbox/=
linux/lib/python2.2/site-packages
> error: file '/usr/local/fitools/sandbox/linux/lib/python2.2/site-packag=
es/pork/pork.py' does not exist
> [16946 refs]
>=20
> Do you accept this as an error?
No, because 'pork.pork' is not allowed in py_modules (it's a hack
that sometimes works, but not intended as feature AFAIK).
--=20
Marc-Andre Lemburg
eGenix.com
Professional Python Software directly from the Source (#1, Mar 19 2003)
>>> Python/Zope Products & Consulting ... http://www.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
Python UK 2003, Oxford: 13 days left
EuroPython 2003, Charleroi, Belgium: 97 days left
From hoel@gl-group.com Wed Mar 19 08:36:38 2003
From: hoel@gl-group.com (=?iso-8859-15?Q?Berthold_H=F6llmann?=)
Date: Wed Mar 19 08:36:38 2003
Subject: [Distutils] Re: Mixing pure python and extension module and multi platform
In-Reply-To: <3E786A99.4070804@lemburg.com>
References: <3E784350.1030103@lemburg.com><3E784F1C.10902@lemburg.com><3E786A99.4070804@lemburg.com>
Message-ID:
"M.-A. Lemburg" writes:
> Berthold H=F6llmann wrote:
> > "M.-A. Lemburg" writes:
> >
> >>Berthold H=F6llmann wrote:
> >>
> >>>"M.-A. Lemburg" writes:
> >>>
...=20
> No, because 'pork.pork' is not allowed in py_modules (it's a hack
> that sometimes works, but not intended as feature AFAIK).
But even this changes do not cure the problem:
>cat setup.py ; python setup.py -n install
from distutils.core import setup,Extension
setup (name =3D "pork.spam",
version =3D "0.0.0",
description =3D "just a test",
author =3D 'Berthold H=F6llmann',
author_email =3D "hoel@GL-Group.com",
ext_modules =3D [Extension('spam', ['spam.c'])],
packages =3D ['pork']
)
Adding parser accelerators ...
Done.
running install
running build
running build_py
not copying pork/pork.py (output up-to-date)
not copying pork/__init__.py (output up-to-date)
running build_ext
skipping 'spam' extension (up-to-date)
running install_lib
copying build/lib.linux-i686-2.2/spam.so -> =
/usr/local/fitools/sandbox/linux/lib/python2.2/site-packages
copying build/lib.linux-i686-2.2/pork/pork.py -> =
/usr/local/fitools/sandbox/linux/lib/python2.2/site-packages/pork
copying build/lib.linux-i686-2.2/pork/__init__.py -> =
/usr/local/fitools/sandbox/linux/lib/python2.2/site-packages/pork
the pure python package still gets installed alongside the only loosly
extension module.
Regards
Berthold
--=20
Dipl.-Ing. Berthold H=F6llmann __ Address:
hoel@GL-Group.com G / \ L Germanischer Lloyd
phone: +49-40-36149-7374 -+----+- Vorsetzen 32/35 P.O.Box 111606
fax : +49-40-36149-7320 \__/ D-20459 Hamburg D-20416 Hamburg
=20
=20
=20
=20
****************************************************
=20
=20
Beachten Sie: Wir moechten Sie informieren, dass die E-Mail-Adresse des =
Germanischen Lloyd sowie unsere Web-Adresse mit Wirkung vom 1. Maerz =
2003 auf den Namen gl-group.com umgestellt wurde.
=20
=20
Dies bedeutet, dass die bisherige Adresse Kurzzeichen@germanlloyd.org =
durch die neue Adresse Kurzzeichen@gl-group.com ersetzt wird. Die =
Homepage des GL ist kuenftig ueber die Adresse 'http://www.gl-group.com' =
aufrufbar. Die bisher verwendeten Adressen bleiben f=FCr eine =
Uebergangsfrist erreichbar.
=20
=20
****************************************************=20
=20
Please notice: We would like to inform you that the e-mail address of =
Germanischer Lloyd as well as our internet address had been changed to =
gl-group.com with effect from 1st March 2003.
=20
=20
This means that the previous address shortmark@germanlloyd.org will be =
replaced by shortmark@gl-group.com. From now on the GL homepage can be =
accessed at the address 'http://www.gl-group.com'. The old addresses =
remain valid for a transitional period.
=20
=20
=20
****************************************************
=20
=20
=20
=20
This e-mail contains confidential information for the exclusive =
attention of the intended addressee. Any access of third parties to this =
e-mail is unauthorised. Any use of this e-mail by unintended recipients =
such as copying, distribution, disclosure etc. is prohibited and may be =
unlawful. When addressed to our clients the content of this e-mail is =
subject to the General Terms and Conditions of GL's Group of Companies =
applicable at the date of this e-mail. =20
=20
GL's Group of Companies does not warrant and/or guarantee that this =
message at the moment of receipt is authentic, correct and its =
communication free of errors, interruption etc.=20
=20
=20
From mal@lemburg.com Wed Mar 19 15:43:04 2003
From: mal@lemburg.com (M.-A. Lemburg)
Date: Wed Mar 19 15:43:04 2003
Subject: [Distutils] Re: Mixing pure python and extension module and multi
platform
In-Reply-To:
References: <3E784350.1030103@lemburg.com><3E784F1C.10902@lemburg.com><3E786A99.4070804@lemburg.com>
Message-ID: <3E78D5FA.1000607@lemburg.com>
Berthold H=F6llmann wrote:
>>No, because 'pork.pork' is not allowed in py_modules (it's a hack
>>that sometimes works, but not intended as feature AFAIK).
>=20
> But even this changes do not cure the problem:
>=20
>>cat setup.py ; python setup.py -n install
As I wrote before: you have to explicitly *tell* distutils to
install in two different directories !
"""
packages/egenix-mx-base> python setup.py install --help
Global options:
--verbose (-v) run verbosely (default)
--quiet (-q) run quietly (turns verbosity off)
--dry-run (-n) don't actually do anything
--help (-h) show detailed help message
Options for 'mx_install' command:
--prefix installation prefix
--exec-prefix (Unix only) prefix for platform-specific files
--home (Unix only) home directory to install under
vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv
--install-base base installation directory (instead of --prefix o=
r --
home)
--install-platbase base installation directory for platform-specific =
files
(instead of --exec-prefix or --home)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
--root install everything relative to this alternate root
directory
--install-purelib installation directory for pure Python module
distributions
--install-platlib installation directory for non-pure module distrib=
utions
--install-lib installation directory for all module distribution=
s
(overrides --install-purelib and --install-platlib=
)
--install-headers installation directory for C/C++ headers
--install-scripts installation directory for Python scripts
--install-data installation directory for data files
--compile (-c) compile .py to .pyc [default]
--no-compile don't compile .py files
--optimize (-O) also compile with optimization: -O1 for "python -O=
", -O2
for "python -OO", and -O0 to disable [default: -O0=
]
--force (-f) force installation (overwrite any existing files)
--skip-build skip rebuilding everything (for testing/debugging)
--record filename in which to record list of installed file=
s
usage: setup.py [global_opts] cmd1 [cmd1_opts] [cmd2 [cmd2_opts] ...]
or: setup.py --help [cmd1 cmd2 ...]
or: setup.py --help-commands
or: setup.py cmd --help
"""
> from distutils.core import setup,Extension
>=20
> setup (name =3D "pork.spam",
> version =3D "0.0.0",
> description =3D "just a test",
> author =3D 'Berthold H=F6llmann',
> author_email =3D "hoel@GL-Group.com",
> ext_modules =3D [Extension('spam', ['spam.c'])],
> packages =3D ['pork']
> )
>=20
> Adding parser accelerators ...
> Done.
> running install
> running build
> running build_py
> not copying pork/pork.py (output up-to-date)
> not copying pork/__init__.py (output up-to-date)
> running build_ext
> skipping 'spam' extension (up-to-date)
> running install_lib
> copying build/lib.linux-i686-2.2/spam.so -> /usr/local/fitools/sandbox/=
linux/lib/python2.2/site-packages
> copying build/lib.linux-i686-2.2/pork/pork.py -> /usr/local/fitools/san=
dbox/linux/lib/python2.2/site-packages/pork
> copying build/lib.linux-i686-2.2/pork/__init__.py -> /usr/local/fitools=
/sandbox/linux/lib/python2.2/site-packages/pork
>=20
> the pure python package still gets installed alongside the only loosly
> extension module.
>=20
> Regards
> Berthold
--=20
Marc-Andre Lemburg
eGenix.com
Professional Python Software directly from the Source (#1, Mar 19 2003)
>>> Python/Zope Products & Consulting ... http://www.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
Python UK 2003, Oxford: 13 days left
EuroPython 2003, Charleroi, Belgium: 97 days left
From krjackson@lbl.gov Wed Mar 19 21:22:23 2003
From: krjackson@lbl.gov (Keith Jackson)
Date: Wed Mar 19 21:22:23 2003
Subject: [Distutils] compilation error
Message-ID: <86E542AE-5A7A-11D7-B202-000A9577489A@lbl.gov>
Does anybody know why I'm getting the following error when compiling an
extension module with gcc and distutils? The compile line works fine
when I run it by hand, but when distutils runs it I get the following
error:
gcc: cannot specify -o with -c or -S and multiple compilations
error: command 'gcc' failed with exit status 1
Here's the line that causes the error:
gcc -DNDEBUG -O3 -I/sw/globus/globus/include/gcc32dbgpthr
-I/sw/include/python2.2 -c src/ftpControl_wrap.c -o
build/temp.darwin-6.4-PowerMacintosh-2.2/ftpControl_wrap.o
Any thoughts?
thx,
--keith
From silviagomez@email.is Fri Mar 21 07:04:06 2003
From: silviagomez@email.is (Jefferson Haley)
Date: Fri Mar 21 07:04:06 2003
Subject: [Distutils] watch what these girls will do for some free money...so they think
Message-ID: >
This is a multi-part message in MIME format.
--D3841C_FCE012C8.6.7_3.
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable
Money isn't everything...or so you were told right?
Well we bet you that it is! Take a look at these girls
who would do absolutely ANYTHING to win over a self made billionaire!
http://www.hotxxxpass.net/pass2/
These hardworking girls think it's their lucky day because Max
the billionaire suitor has fallen upon them and their wonderful
talents! Watch them show themselves off to impress Max!
You won't believe what these girls will do to get a piece of Max's pie!
http://www.hotxxxpass.net/pass2/
iblsm dgims
cmncrgsnssd c
--D3841C_FCE012C8.6.7_3.--
From bhoel@web.de Fri Mar 21 16:59:02 2003
From: bhoel@web.de (Berthold =?iso-8859-1?q?H=F6llmann?=)
Date: Fri Mar 21 16:59:02 2003
Subject: [Distutils] Re: Mixing pure python and extension module and multi platform
In-Reply-To: <3E78D5FA.1000607@lemburg.com>
References:
<3E784350.1030103@lemburg.com>
<3E784F1C.10902@lemburg.com>
<3E786A99.4070804@lemburg.com>
<3E78D5FA.1000607@lemburg.com>
Message-ID:
"M.-A. Lemburg" writes:
> Berthold H=F6llmann wrote:
> >>No, because 'pork.pork' is not allowed in py_modules (it's a hack
> >>that sometimes works, but not intended as feature AFAIK).
> > But even this changes do not cure the problem:
> >
> >>cat setup.py ; python setup.py -n install
>=20
> As I wrote before: you have to explicitly *tell* distutils to
> install in two different directories !
>=20
> vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv
>=20
> --install-base base installation directory (instead of --prefix o=
r --
> home)
> --install-platbase base installation directory for platform-specific =
files
> (instead of --exec-prefix or --home)
>=20
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Sorry, but I still understand why. My Python/distutil installation has
the default --install-base as --prefix which is already different from
--install-platbase, or --exec-prefix. If I install a pure Python
module or package it gets installed into "--prefix" which is
"/usr/local/fitools/sandbox/lib/python2.2/site-packages" and packages
holding extension modules get installed into "--exec-prefix" which is
"/usr/local/fitools/sandbox/linux/lib/python2.2/site-packages". Why
doesn't it work when I use both in one "setup" command? Default values
for "--prefix" and "--exec-prefix" are taken from the initial
"./configure" in the python source tree, arent they?=20
Regards
Berthold
--=20
bhoel@web.de / http://starship.python.net/crew/bhoel/
It is unlawful to use this email address for unsolicited ads
(USC Title 47 Sec.227). I will assess a US$500 charge for
reviewing and deleting each unsolicited ad.
From cburns1@swarthmore.edu Mon Mar 24 21:30:02 2003
From: cburns1@swarthmore.edu (Chris Burns)
Date: Mon Mar 24 21:30:02 2003
Subject: [Distutils] Extension modules and python modules
Message-ID:
Hi,
Sorry if this has been answered before: I looked through the archives
but couldn't find exactly the same problem I'm encountering.
I'm trying to put together a distribution that has a C extension as well
as a python module that wraps the extension, giving it a friendlier
interface (call the first _spam.so and the second spam.py: spam.py
imports _spam.so). I've gotten the setup.py script to correctly compile
and install, but when I try to make a binary distribution (bdist or
bdist_rpm), it doesn't include the C extension, just the python module.
This is such a basic thing (and common), I must be missing something really
basic. I'd appreciate any help. My setup.py is included below. I'm using
python 2.2.2.
Chris
#!/usr/bin/env python
from distutils.core import setup, Extension
from distutils.sysconfig import get_python_inc
from distutils.sysconfig import get_python_lib
import os
num_lib_dir = os.path.join(get_python_lib(plat_specific=1), "Numeric")
num_inc_dir = os.path.join(get_python_inc(plat_specific=1), "Numeric")
ext = Extension("_spam", ["spam.c"],
include_dirs=[num_inc_dir],
library_dirs=[num_lib_dir])
setup(name="spam",
version="0.5",
description="Spam Library",
author="Chris Burns",
ext_modules=[ext],
py_modules=['spam'])
--
Chris Burns
Visiting Assistant Professor
Dept. of physics and astronomy, Swarthmore College
cburns1@swarthmore.edu http://hven.swarthmore.edu/~burns
From freemyer@NorcrossGroup.com Thu Mar 27 13:46:02 2003
From: freemyer@NorcrossGroup.com (Greg Freemyer)
Date: Thu Mar 27 13:46:02 2003
Subject: [Distutils] Newbie
Message-ID: <20030327184645.REBA11325.imf33bis.bellsouth.net@tiger2>
I'm trying to use distutils for the first time.
I am trying to get a python package that builds/installs in cygwin to also =
build/install in Win32.
I have already followed the full recipe at
http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/82826
Is that a good starting point? It worked fine.
Is this the correct mailing list for questions?
Is there a searchable archive for this list?
My first question is:
The command "python setup.py install" causes a DLL to be built.
i.e. python is the cygwin python.
>From the same cygwin shell, the command=20
ntpython setup.py install --compiler=3Dmingw32
appears to work, but a corresponding DLL is not built.
i.e. ntpython is the Win32 native python
Do I need to modify setup.py?
=20
Thanks
Greg
--=20
Greg Freemyer
From gregory_r_warnes@groton.pfizer.com Sat Mar 29 16:22:01 2003
From: gregory_r_warnes@groton.pfizer.com (Warnes, Gregory R)
Date: Sat Mar 29 16:22:01 2003
Subject: [Distutils] Help building module on cygwin
Message-ID:
Hi, I'm working to port a python module from Unix to Windows under cygwin.
I've made enough changes that there are no compilation errors and the DLLl
file gets built, but python generates an error message when loading it:
$ python
Python 2.2.2 (#1, Mar 9 2003, 08:18:26)
[GCC 3.2 20020927 (prerelease)] on cygwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import _rpy.dll
Traceback (most recent call last):
File "", line 1, in ?
ImportError: dlopen: Win32 error 193
I built the package under
$ uname -a
CYGWIN_NT-5.0 GRDGROL780DCZZ 1.3.22(0.78/3/2) 2003-03-18 09:20 i686 unknown
unknown Cygwin
using
$ python setup.py build
running build
running build_py
creating build
creating build/lib.cygwin-1.3.22-i686-2.2
copying rpy.py -> build/lib.cygwin-1.3.22-i686-2.2
copying io.py -> build/lib.cygwin-1.3.22-i686-2.2
running build_ext
building '_rpy' extension
creating build/temp.cygwin-1.3.22-i686-2.2
gcc -DNDEBUG -DUSE_DL_IMPORT -UPRE_2_2 -UWITH_NUMERIC
-IC:/Progra~1/R/rw1062/src/include -I/home/warneg/src/R-1.6.2/src/include
-Isrc -I/usr/include/python2.2 -c src/rpymodule.c -o
build/temp.cygwin-1.3.22-i686-2.2/rpymodule.o
[.. more compilation lines ommitted ..]
gcc -shared -Wl,--enable-auto-image-base
build/temp.cygwin-1.3.22-i686-2.2/rpymodule.o
build/temp.cygwin-1.3.22-i686-2.2/R_eval.o
build/temp.cygwin-1.3.22-i686-2.2/io.o
build/temp.cygwin-1.3.22-i686-2.2/setenv.o -LC:/Progra~1/R/rw1062/bin
-LC:/rpy/bin -L/usr/lib/python2.2/config -lR -lpython2.2 -o
build/lib.cygwin-1.3.22-i686-2.2/_rpy.dll
Info: resolving _R_NilValue by linking to __imp__R_NilValue (auto-import)
Info: resolving _R_NamesSymbol by linking to __imp__R_NamesSymbol
(auto-import)
Info: resolving _R_LevelsSymbol by linking to __imp__R_LevelsSymbol
(auto-import)
Info: resolving _R_DimSymbol by linking to __imp__R_DimSymbol (auto-import)
Info: resolving _R_ClassSymbol by linking to __imp__R_ClassSymbol
(auto-import)
Info: resolving _R_GlobalEnv by linking to __imp__R_GlobalEnv (auto-import)
Info: resolving _R_UnboundValue by linking to __imp__R_UnboundValue
(auto-import)
I'm not very familiar with programming under Cygwin. Can someone suggest
how to determine exactly what the problem is?
Thanks,
-Greg
LEGAL NOTICE
Unless expressly stated otherwise, this message is confidential and may be privileged. It is intended for the addressee(s) only. Access to this E-mail by anyone else is unauthorized. If you are not an addressee, any disclosure or copying of the contents of this E-mail or any action taken (or not taken) in reliance on it is unauthorized and may be unlawful. If you are not an addressee, please inform the sender immediately.
From jason@tishler.net Mon Mar 31 07:50:01 2003
From: jason@tishler.net (Jason Tishler)
Date: Mon Mar 31 07:50:01 2003
Subject: [Distutils] Help building module on cygwin
In-Reply-To:
References:
Message-ID: <20030331125625.GA3052@tishler.net>
Greg,
On Sat, Mar 29, 2003 at 04:20:57PM -0500, Warnes, Gregory R wrote:
> >>> import _rpy.dll
> Traceback (most recent call last):
> File "", line 1, in ?
> ImportError: dlopen: Win32 error 193
^^^^^^^^^^^^^^^
It appears you built a "bad" shared extension module (i.e., DLL):
$ fgrep 193L /usr/include/w32api/winerror.h
#define ERROR_BAD_EXE_FORMAT 193L
> gcc -shared -Wl,--enable-auto-image-base
> build/temp.cygwin-1.3.22-i686-2.2/rpymodule.o
> build/temp.cygwin-1.3.22-i686-2.2/R_eval.o
> build/temp.cygwin-1.3.22-i686-2.2/io.o
> build/temp.cygwin-1.3.22-i686-2.2/setenv.o -LC:/Progra~1/R/rw1062/bin
^^^^^^^^^^^^^^^^^^^^^^^^^^
> -LC:/rpy/bin -L/usr/lib/python2.2/config -lR -lpython2.2 -o
^^^^^^^^^^^^ ^^^
The above raises the following questions/issues:
1. Are you linking directly against the DLL (i.e., R.dll) or the import
library (i.e., R.dll.a or R.a)? Since the flagged -L options above end
in "bin", I'm concerned that it's the former. If my WAG is correct,
then linking against the import library may solve your problem. Note
that you should only link directly against DLLs as a last resort.
2. You should use Posix style paths in Cygwin. Note that this is not
causing your problem, but I find the Win32 style paths aesthetically
unpleasing. :,)
Jason
--
PGP/GPG Key: http://www.tishler.net/jason/pubkey.asc or key servers
Fingerprint: 7A73 1405 7F2B E669 C19D 8784 1AFD E4CC ECF4 8EF6