First: thank you distutils-sig, and especially Tarek, for spearheading this
effort!
I'm particularly excited about the "Distribution" object that this PEP
specifies. I've been waiting for a long time to be able to load an object
describing a distribution, rather than running setup.py and hoping that it
mutated the right state!
On Apr 1, 2010, at 5:51 PM, Tarek Ziadé wrote:
> - to provide a basic *uninstaller* feature in the distutils2 project.
Second: It seems to me that a major missing feature in the PEP is the ability
to run some code during installation and uninstallation, especially since it is
so easy to run ad-hoc code in setup.py with no way of un-doing what it did.
Twisted's plugin system needs this in order to update a plugin index so that
plugins can be quickly scanned without being loaded. However, since this is
arguably a design flaw in Twisted that should be fixed, I should point out
there are other systems that have similar requirements, which are considerably
less mutable: COM registration, other registry keys, adding / removing crontab
entries, windows services, start menu items, XDG desktop / menu entries, login
items, edits to the user's shell configuration, etc. The list goes on and on.
I appreciate the "installer marker" feature, since that will at least allow
easy_install or pip or something like them to implement this feature with
minimal risk of being broken by built-in package management tools, but it seems
like such a simple addition that it would be a shame to leave it out. If we
could get rid of setup.py entirely so that it wasn't so easy to run ad-hoc
stuff during install, I would be happy to leave it to them :).
I realize that there are a lot of potential complexities that might creep into
the process of determining the execution environment for the code in question,
but I personally think it would be good enough to say "You'd better be darn
sure to encode all of the run-time state that you need into your own script, or
it might break."
Third: The PEP is silent on what happens to files whose hash _has_ changed from
its install-time value. I guess the implied plan would be to leave them in
place. However, this may have nasty side-effects; for example, if the files
are test files, then they might be loaded during test discovery, and report
exceptions since the code that they're testing has been removed. My suggestion
would be to have a specific "quarantine" area where the distutils uninstaller
can put modified files that would have been removed as part of a specific
distribution, so they aren't still present on PYTHONPATH. I can also think of
reasons why you might not want to do this, but either way, the consequence of
changing an installed file should be made explicitly clear in the PEP: if they
are to be left in place, it should emphasize that point.
Finally, one minor bit of bikeshedding, of which I promise to say nothing more
if there is not unanimous agreement: I dislike the use of "get_" in function
names, since it adds more characters without really adding more information.
get_file_users is particularly bad, since it makes me think that it's going to
return a list of processes with a file open, or a list of UIDs or something
like that. I suggest these names instead:
get_distributions() -> active_distributions()
get_distribution(name) -> active_distribution_named(name)
get_file_users(path) -> distributions_using_path(path)
where "active" means "on the current sys.path and thereby accessible by
'import'". This naming would also make the behavior of get_file_users a bit
clearer; if the intention is to return only active, loadable distributions (you
don't want to be able to use get_file_users to inspect other Python
installations or virtualenvs) it could be called
active_distributions_using_path.
Thanks again to the PEP's author and many contributors,
-glyph
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
