RetroSearch Browse

Thu Jan 10 00:12:59 CET 2008 · https://mail.python.org/pipermail/python-dev/2008-January/076056.html

On 09/01/2008, Christian Heimes <lists at cheimes.de> wrote:
> Paul Moore wrote:
> > If you are suggesting that a file intended to be viewed/edited by a
> > user manually should go in AppData, then please be explicit. We can
> > then argue the concrete issues, rather than just theoretical
> > principles.
>
> I'm frustrated as well. Neither AppData nor MyDocuments fulfill our
> requirements.

For what? If you're talking about a per-user site-packages directory,
I have no problem with AppData (as Michael said, there's no intention
that users be able to edit the files). Of course,
modules/packages/extensions don't really qualify as application
*data*, so it is a somewhat odd usage certainly, but it's not
disastrous.

Windows doesn't really have a concept of a per-user application code directory.

Come to that, if I use a bdist_wininst installer to install a package
in my personal site packages, then I log off and you log on, would you
expect to see my package when you look in add/remove programs? Would
you expect to be able to uninstall it? Would you expect to be able to
install a personal copy of your own? What would we see in add/remove
programs *then*??

No matter how you cut it, Windows isn't designed for per-user
installable programs. Maybe a per-user site-packages just isn't
appropriate on Windows.

Paul.

PS This is mostly theoretical for me, as I don't have a personal need
for a per-user site packages directory on any of the machines I use.

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://mail.python.org/pipermail/python-dev/2008-January/076056.html below:

[Python-Dev] pkgutil, pkg_resource and Python 3.0 name space packages