Hello,
I had a look at Python2.0 over the week end and I noticed that the installation
procedure creates a site-packages directory under $prefix but not under
$exec_prefix.
Is there a consensus about wher packages containing a mix of .py and .so files
should go ?
Should we ise the PyOpenGL strategy of extending the path with a sub-directory
for platform specific stuff at run time ? or should we place all .so files in
lib-dynload ? or should we have a site-packages under $exec_prefix and
duplicate the .py files (my concern here is not disk space but rather keeping
these files in sync!)
I know I have already brought this up ! so forgive me .... but I rather have a
mechanism allowing Python to search platform dependent extensions first (to get
fast versions if they are available) and then search platform independent
packages even if a package match has be found earlier.
Thanks for any thoughts/hints/advise on this
-Michel
--
-----------------------------------------------------------------------
>>>>>>>>>> AREA CODE CHANGE <<<<<<<<< we are now 858 !!!!!!!
Michel F. Sanner Ph.D. The Scripps Research Institute
Assistant Professor Department of Molecular Biology
10550 North Torrey Pines Road
Tel. (858) 784-2341 La Jolla, CA 92037
Fax. (858) 784-2860
sanner(a)scripps.edu http://www.scripps.edu/sanner
-----------------------------------------------------------------------
is there a simple way to get distutils to compile
an extension for my end-user app? i need a small
extension compiled and just placed in the current
directory (not installed to PYTHONHOME)
i'm not sure if distutils supports anything like this,
but i imagine someone out there has done something
similar? i'd be glad to get my hands on some info
or examples, thanks
This seems odd to me...
When I build a source distribution with python setup.py sdist, my
MANIFEST.in file is not included in the resulting archive. This seems wrong,
as without the MANIFEST.in, I cannot rebuild the distribution.
I would assume that building a sdist should create save everything needed to
rebuild the package, its sdist, etc etc, from scratch.
Another thought - a "reallyclean" command would be nice (deletes all
intermediate and generated files - essentially all of the "build" and "dist"
directories, at least...
Thanks,
Paul Moore
What license is Distutils distributed under? I downloaded
Distutils-1.0.1.tar.gz but there was no mention in any file of
redistribution terms.
--
albert chin (china(a)thewrittenword.com)
i have a set of python extension modules that are building
and installing with distutils. it is finally working very
well, and i'm very happy with the results.
i'd like to start using distutils to create my source and
binary distributions. everything is working for the most part
(i have a feeling i'll be looking into the code for further
refinements :]). anyways, when i create my binary distribution
it is not packaging any of the examples or help files. i
guess the problem is; where should these files go???
it seems like this type of stuff hasn't been nailed down yet?
what i was thinking would be ideal, is for my binary
distributions to come exactly like the source distributions,
but with the compiled files in the "build" directory included.
this is mainly for windows i suppose? but then users without
compilers could still do the "setup.py install", and there
would be no need for compilation, since the binaries would
already be in the build directories.
is that a clean method for the binary releases? to me it sounds
like the best plan, i suppose i could just zip up my source
directory and include the "build" for my binary distributions,
but i was checking if distutils already supported something
similar.
just trying to figure this all out, thanks
re: CREATING PYTHON EXTENSIONS USING BORLAND'S FREE COMPILER
http://www.cyberus.ca/~g_will/pyExtenDL.shtml
(I'm copying Greg Ward and the distutils-sig to see if we can't build
cooperate here.)
Gordon Williams wrote:
>
> This is really a tutorial plus a few other things rather than a "package".
> It is for creating extensions using the Borland compiler that can be used
> with the Microsoft compiled standard distribution. Maybe this wasn't clear
> in the [ANN]?
>
> Download it and have a look. I'm not familiar with distutils (I just had a
> quick read) but I don't think that it is appropriate. If you think that
> distutils should be used please get back to me.
Gordon:
You've written some nice instructions on how to obtain and install the
Borland free compiler. You provide instructions on how to customize
batch files to compile and link extensions on Windows.
Actually, 'distutils' is precisely designed to build extensions. Rather
than .bat scripts, you describe how to build your extension in a
'setup.py' file. The advantage of using distutils is that it can
compile your code on multiple platforms, with a minimum amount of
machine dependencies in the script. And of course, distutils ships
standard with Python 2.0.
distutils now works with the Microsoft Visual C compiler. There was
some work done on using the free Borland compiler, but I don't know if
it was finished.
Greg (and the distutils gang) - is the free Borland compiler support for
Windows working at present?
> If you are interested, the codec is available at:
> http://pseudo.grad.sccs.chukyo-u.ac.jp/~kajiyama/python/iso_2022_7bit.py.gz
I just had a look, and it seems like an interesting package. I'm
slightly confused about the installation procedure, though.
Installing into python2.0/encodings/{euc_jp,shift_jis,japanese}
doesn't look right to me - add-on packages should be capable of
installing into site-packages by default.
I believe it would actually work if you just install without any
arguments to setup.py. euc_jp would then end-up in
python2.0/site-packages. Later, when you do
u"Hello".encode("euc-jp")
it looks for a codec. Here, encodings.__init__.search_function do
modname = encoding.replace('-', '_')
modname = aliases.aliases.get(modname,modname)
try:
mod = __import__(modname,globals(),locals(),'*')
except ImportError,why:
_cache[encoding] = None
return None
First, encoding becomes euc_jp. With no registered aliases, it would
then call __import__ with "euc_jp", which will find the codec in
site-packages.
In the long run, I'd hope that distutils provides a mean to install
additional codecs, e.g via
setup( ...
codecs = ['japanese']
...)
Then, distutils would collect all these strings, and importing codecs
would roughly do
for package in distutils.registered_codec_packages:
p=__import__(package,global(),locals(),"*")
p.register()
japanese/__init__.py would provide a register function which registers
another search_function, which would load euc_jp and shift_jis on
demand. That way, users could install additional codecs which are
available to everybody on the system, without having to hack the
Python library proper.
Regards,
Martin
.
Hi all,
the first patch fixes the debugging routine dump_dirs. This bug occurs
only with DISTUTILS_DEBUG defined.
The second patch fixes the initialization of self.outfiles in the
install_scripts command.
Greetings, Bastian
On 22 October 2000, James Thompson said:
> I hate to bother you personally but the list is screwed and I'm pushing
> for a new release for our app w/ distutil support today.
Bad luck! Due to the Starship outage, your mail to me sat in limbo for
almost a week. Dunno what's up with the Distutils list...
> I have an application that is partially modules, a few packages, and a
> final application or two.
>
> I'd like the application to end up in equiv of autoconfs prefix (/usr/bin,
> /usr/local/bin) and everything else to end up is a gnue directory (or
> below it in as a package)
>
> site-packages/gnue
> site-packages/gnue/forms/*
> site-packages/gnue/misc/*
>
> I've found that distutils (1.0.1) doesn't allow mixing packages, modules
> in setup.py so I assume this will require me doing every thing as a
> package.
That's a feature -- it's meant to *encourage* people to put their
modules into packages. ;-)
But if you still have "legacy" top-level modules, that's OK: just tell
the Distutils to process the "root package". Eg.
packages = ['', 'gnue', 'gnue.forms', 'gnue.misc']
Every "root package" module found in your source tree will wind up in
site-packages, unless you specify a .pth file with the 'extra_path'
option.
> But I can't find anything on how to get the main app in
> /usr/local/bin or how to include docs/man pages etc.
For the main app:
scripts = ['script']
will copy "script" to /usr/local/bin (or whatever the prefix of the
current Python interprerter is), with the #! line fixed to point to the
interpreter used for the build.
Docs and man pages are not handled, because there is no standard
documentation format in the Python world. That's a bug, but not
one I can fix single-handedly. ;-(
Greg
--
Greg Ward gward(a)python.net
Greg et al,
If anyone still has control over the distutils documentation stored here:
http://www.python.org/sigs/distutils-sig/doc/dist/dist.html
You might want to update it to the latest version. A question was recently
posted to the newsgroup about the missing "extensions" keyword argument for
setup() -- which is correctly labelled "ext_modules" in the latest version
of the distutils documentation bundled with Python 2.0.
