469,927 Members | 1,887 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 469,927 developers. It's quick & easy.

Q: distutils - name clash protection?

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:
from mb import mbsql
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:
from SamRushing import calldll


"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





Jul 18 '05 #1
3 1126

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
Jul 18 '05 #2
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
Jul 18 '05 #3
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.

Jul 18 '05 #4

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

reply views Thread by Jorge Godoy | last post: by
1 post views Thread by Mathieu Malaterre | last post: by
1 post views Thread by Terry Hancock | last post: by
reply views Thread by Maarten Sneep | last post: by
2 posts views Thread by Jerry He | last post: by
6 posts views Thread by ajikoe | last post: by
7 posts views Thread by vedrandekovic | last post: by
12 posts views Thread by Abhishek Mishra | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.