From: Andrew Kuchling [mailto:akuchlin@mems-exchange.org]
> I'd also really like to get this checked in by next Monday, and am
> noting the tendency toward feature creep starting. Support for
> versioncheck and multiple authors and such things are all good ideas,
> but they'll require writing more code, and we're already at the beta
> stage, so I'm really anxious to minimize the changes. Shall we simply
> vote on the issue? RFC-822 or simple XML (from Paul's algorithm cited
> above)? +/-1, +/- 0 voting, as on python-dev.
+1 for RFC-822
-0 for XML
I agree, let's KISS and get something out. Overdesign is not a virtue - CPAN
"just growed".
Paul
I'd like to suggest the convention that uninstall logs be placed in an
"uninstall" directory. Python top-level directories are messy enough as
it is. The convention and syntax described here is fine with me:
http://mail.python.org/pipermail/distutils-sig/2001-February/001991.html
All install commands should generate the appropriate logs. It should
also be possible to insert an uninstall/remove_packagename.py for
undoing-anything unusual (e.g. if the install modified an Apache config
file or something). remove_packagename.py functions should be
exceedingly rare but at ActiveState we have taken the position that
people should be able to do arbitrary things in installers and
uninstallers....more on that later...
--
Python:
Programming the way
Guido
indented it.
I'm forwarding this message to the distutils people; apparently, someone
wants to allow spaces within recursive-include pathnames. To allow this,
I've written a small "splitWithQuotes()" function that handles this sort
of weird string splitting.
There's probably a much better way to write this mini-parser (can we
employ Python's line parser?), but in any case, I had fun writing this.
If we replace the call to spring.split() in _parse_template_line
(filelist.py):
###
def _parse_template_line (self, line):
words = string.split(line)
###
with
words = splitwithquotes(line)
this should allow Dmitry's recursive-include to work, if everything else
holds together (which it might not. *grin*)
Is this feasible?
---------- Forwarded message ----------
Date: Mon, 12 Mar 2001 06:27:32 -0800 (PST)
From: Daniel Yoo <dyoo(a)hkn.eecs.berkeley.edu>
To: Balabanov Dmitry <dimonb(a)beep.ru>
Cc: help(a)python.org
Subject: Re: [Python-Help] help with distutils
On Sat, 10 Mar 2001, Balabanov Dmitry wrote:
> Hi!!
> Problem is very simple but i can't solve it...
> I have such string in MANIFEST.in:
> recursive-include 'Max Fray' *.txt
> But `python setup.py sdist --manifest-only` spawns:
> running sdist
> warning: sdist: missing required meta-data: url
> reading manifest template 'MANIFEST.in'
> warning: no files found matching 'Fray'' under directory ''Max'
> warning: no files found matching '*.txt' under directory ''Max'
> writing manifest file 'MANIFEST'
First of all, apologies for the very late response. It's been a long
week.
Hmmm.. the problem is that the DistUtils assume that the directories don't
have a space in them. That's why it's parsing the directories
incorrectly.
Specifically, the problem lies in the function _parse_template_line() in
filelist.py of the Python Distutils, around line 111 --- they use a simple
string.split(), which doesn't look at quoted directories. That's why
we're getting those weird error messages.
Given this, I'm not quite sure what the elegant solution to this would be.
Is it possible to rename the directory "Max Fray" to Max_Fray without too
much pain? Also, please contact the DistUtils SIG at:
http://mail.python.org/mailman/listinfo/distutils-sig
The best way to solve this is to get the distutils to be a little smarter
when it comes to reading in those manifest lines; I'll see if I have time
to provide a patch to this later.
_______________________________________________
Python-Help maillist - Python-Help(a)python.org
http://mail.python.org/mailman/listinfo/python-help
Is there a convention for shipping post-install scripts through
distutils? We've taken the route of simply shipping the setup.py with
the PPM. Pre- or post- or even mid-install commands can go in that
script. I'd like to know what the other bdist_*'s do. I see something
about an install_script in the RPM one but I don't understand it well
enough to know what it is really doing.
Even though Python PPM is only a week old, we've already taken advantage
of this feature to install packages that have both Python and Perl
components. I'd like to use a shared convention so that module authors
can depend upon it. "Good" bdist_ commands should have a way to launch a
post-install script. The same should go for uninstall...
--
Python:
Programming the way
Guido
indented it.
Hi Guys,
I've added a patch on sourceforge to allow distribution
meta-data to be written to an XML file. This should help the
catalog effort.
http://sourceforge.net/tracker/index.phpfunc=detail&aid=407434&group_id=547…
The reason for the patch is that I've found out that it's
hard to extract distribution meta-data by running setup.py.
Often setup.py will not run if you don't have the required
environment. Also, there is an inherent security problem in
running setup.py to extra meta-data if you don't trust the
distribution.
By writing meta-data to a file programs like the catalog can
find out the meta-data of a distribution without running any
distribution code. In fact all they'll have to do is this:
from distutils.dist import DistributionMetadata
m=DistributionMetadata()
f=open('metadata.xml', 'rb')
m.read_data(f)
f.close()
# At this point m is a dictionary mapping
# meta-data names to values
-Amos
P.S. I am not attached to any paticular format for the
meta-data file. I chose XML since it seemed reasonable and
easy. I also considered RFC822. In any event, if we decide
that another format is better, all that is needed is to
change the 'write_data' and 'read_data' methods on the
DistributionMetadata class.
Following the IPC9 discussion, let's continue the thread on metadata.
Here's a list I posted to the Catalog-SIG back in November.
Information about a package
===========================
Name
Version
Supported Platforms
Description
Keywords
Homepage URL
Author IDs
License
Download link
Date of release
Leaving out for now: dependency information, except perhaps as just a
text field
Information about an author
===========================
Name
Home page
GnuPG/PGP key (both the actual key, and just the ID)
E-mail address (used as ID?)
E-mail address public: y/n
Information about a document
============================
Name
Author
Description
URL of HTML version
URL of printable version
URL and format of downloadable version
(Any of these URLs can be omitted if not applicable.)
The "Information about a document" section is only relevant to a
catalog that includes non-software things such as documentation, and
can probably be ignored for now. The "Information about an author"
section makes sense for a CPAN-like system where authors are
registered as independent entities, but not for one where packages are
the only entities. On the other hand, maybe registering developers is
worth preserving; otherwise you'd have to put your URL and GPG key in
every single package you maintain, which is kind of annoying.
I plan to write this up as a PEP, and explain the contents and
semantics of each field in detail.
Comparison with OSD
===================
Additional fields in OSD:
LANGUAGE: for the implementation language, I assume, and not the human
language it's documented in?
OS, OSVERSION: operating system required to run this package.
PYTHONCORE: Version of Python required to run this package.
PROCESSOR: CPU required to run this package.
CODEBASE, INSTALL, UNINSTALL: references to downloadable code, to an
install script, to an uninstall script.
Given the existence of the Distutils, the last 3 fields all collapse
down into the code's location. PROCESSOR seems only marginally useful
(can you name a Python extension that runs on only one processor?),
but leaving it in is no big deal.
OSD does not have fields for keywords or for a release date.
Looking at the PAD format, there's little new there that's applicable;
about the only thing is a field to indicate if a release is a minor or
major update (perhaps there's a 'Security Bug' value, too).
--amk
Hi!
I am trying to use distutils with boost (www.boost.org) on MD 7.0 Linux
and with gcc 2.95.2.
When compiling/linking C++ codes, distutils uses gcc compiler. But then
importing shared module fails (it cannot find `cerr').
When I manually used g++ for compiling/linking, import succeeded.
Now I use the following code fragment
++++++++++++++++++++++++++++++++++++++++++++++
from distutils import sysconfig
save_init_posix = sysconfig._init_posix
def my_init_posix():
print 'my_init_posix: changing gcc to g++'
save_init_posix()
g = sysconfig._config_vars
g['CC'] = 'g++'
g['LDSHARED'] = 'g++ -shared'
sysconfig._init_posix = my_init_posix
+++++++++++++++++++++++++++++++++++++++++++++
in my setup.py file.
I am wondering if there is a "nicer" way to change compiler and
linker program in setup.py?
If a package contains both C and C++ codes, then the above will not
work. Any ideas how to build such mixed extension modules?
And I'll appreciate an example setup.py that uses boost.
Pearu
>>>>> "Thomas" == Thomas Heller <thomas.heller(a)ion-tof.com> writes:
Thomas> (I think the following should go into the docs.
Thomas> Comments?)
Thomas> [Enrico Sirola]
>> Ah! This is just what I needed. I've read the distutils' docs
>> on www.python.org, but the "Extending the distutils" chapter is
>> empty. I do i use this test class from a setup.py? Thanks,
>> Enrico
Thomas> First you have to make the test class known to the
Thomas> setup-script:
Thomas> setup(..., cmd_class = {'test': test}, ...)
Thomas> This allows to run 'python setup.py test', and since the
Thomas> 'run' method of the test class contains a call to build
Thomas> self.run_command('build'), the build step will be run
Thomas> first, and then your test.
Thomas> If you want the 'test'-step always be run at the end of
Thomas> the build-steps, you can install 'test' as a sub-command
Thomas> of build (Remove or comment-out the
Thomas> "self.run_command('build')" line before trying this,
Thomas> otherwise test and build would call each other
Thomas> recursively) in this way:
Thomas> from distutils.command import build
Thomas> build.build.sub_commands.append(('test', None))
Thomas> setup(.....)
Thomas> You could replace the 'None' above by a method
Thomas> test.has_tests() for example which would answer true if
Thomas> there are test cases, false otherwise.
thanks a lot, i just tried and it works quite well,
Enrico
--
Enrico Sirola <enri(a)users.sourceforge.net>
Key fingerprint = B446 7332 ED55 BC68 5FE8 DE0F 98DF EC86 377F E07F
>>>>> "Thomas" == Thomas Heller <thomas.heller(a)ion-tof.com> writes:
Thomas> I still have this code in one of my setup-scripts, the
Thomas> original version should be still in the archives, also
Thomas> some discussion about a test command:
Ah! This is just what I needed. I've read the distutils' docs on
www.python.org, but the "Extending the distutils" chapter is empty. I
do i use this test class from a setup.py?
Thanks,
Enrico
--
Enrico Sirola <enri(a)users.sourceforge.net>
Key fingerprint = B446 7332 ED55 BC68 5FE8 DE0F 98DF EC86 377F E07F
From: Thomas Heller [mailto:thomas.heller@ion-tof.com]
>
> I still have this code in one of my setup-scripts,
> the original version should be still in the archives,
> also some discussion about a test command:
I found the discussion. It looked good, but it seemed to peter out without
consensus or any action. Can I suggest that *something* needs to be built
in, even if it is minimal. Users can always override the default with
something more complex, if they need to (or want to).
My personal preference is to go with something like Greg Ward's suggestions,
based on the Perl test harness. But there was never any code implemented to
support this.
Your version, if I understand it, simply imports each test module and runs
its test() routine. I'm not too happy that the "OK/Not OK" reporting is left
solely to the test routine - I'd rather there be a standard format. But
maybe that's a job for a standard "test harness" module, rather than for the
distutils command. Your version also seems to include code coverage
reporting (which I *like*!!) but I can't find the code_coverage module in my
distribution - is it a local module?
But as I said, I'd rather see your version (with all my reservations)
included and standard, than have nothing at all.
Paul.
