Q: distutils - name clash protection?

[Martin Bless]

Q: How do I make my setup procedure safe?
Q: How can I let users specify a different destination dir?

By now I think I have some useful modules I'd like to share. In "my
world" everything is centered around my name, therefor my stuff
typically lives in or beneath a package "mb". To use a module - for
example - I do:

Following this approach a minimalistic setup.py looks like this:

#
# minimal setup.py
#
from distutils.core import setup
setup(name = "mbsql",
version="0.1.0",
packages = ["mb","mb.mbsql"],)

While this is fine in my little world I hate the idea that somebody
else gets unexpectedly and with no warning overwritten what maybe was
in his own "mb" package.

(1) There should be a check built into the sdist that issues as
warning ('mb' already exists - continue?).

(2) Or even better: If the user already has an existing "mb" package:
let him specify a name he likes, maybe "mbmbmb". For example some
tools I found on the web live in a package "SamRushing" on my
installation. And I like the according import statement for its
clarity:

"distutils" is wonderful but a beast of its own if it comes to
customizing. I'd like to know:

Q: What's the best way to accomplish (1) and/or (2)?

Thank you very much,

mb - Martin Bless

 

[Skip Montanaro]

Martin> Q: How do I make my setup procedure safe?

Try picking something a bit more unique for a package name than "mb". How
about "mbless"?

Martin> Q: How can I let users specify a different destination dir?

Try:

python setup.py install --help

Skip

 

[Heiko Wundram]

Repost, as only sent to op...

Am Montag, 26. Juli 2004 22:53 schrieb Martin Bless:

Q: How do I make my setup procedure safe?
Q: How can I let users specify a different destination dir?

Simple answer to both of the questions: there's no way to do this at the
moment. If you're interested in implementing something like this, read on PEP
262[1], and help me implement the necessary architecture...

I'm currently working on writing up a proposal myself (as PEP 262 doesn't go
quite as far as I would like it to go), and I've already written some code
which does what PEP 262 proposes (to have a database of installed modules)
and more (letting users specify a destination directory for the module,
having automatic support for user directories if you can't install the module
as root, etc.), but I'm not finished with yet...

Anyway, feel free to contact me if you're willing to help. Once the draft of
the "new" PEP is finished, I'll send it to python-dev, as I said last week;
it'll only be a matter of days now, as I'm currently in preparation for my
medicine exams this week and this weekend...

Heiko.

[1] http://www.python.org/peps/pep-0262.html

 

[Calvin Spealman]

I went ahead and looked at 262 as this thread caught my eye and just wanted
to give my two cents: Might be a good idea to not define the format but
only the API? Or, at least to specify that while you may count on the API
you can not count on exactly how it is implemented? Why duplicate the work
done by a system's native package management system(s) if they store the
information you need? Though it would definitely be a powerful tool to
access this information through a standardized Python API, even for only
Python Packages.