What's missing from easy_install
1. easy_remove! 2. Various utilities to provide query package management. - easy_install --list (list files installed)
On Tue, Apr 7, 2009 at 8:05 AM, Neal Becker <ndbecker2@gmail.com> wrote:
1. easy_remove!
2. Various utilities to provide query package management. - easy_install --list (list files installed)
Implementing is easier said than done, and I think you got that idea from the lack of response from folks... HTH, -Garrett
On Sun, Apr 12, 2009, Garrett Cooper wrote:
On Tue, Apr 7, 2009 at 8:05 AM, Neal Becker <ndbecker2@gmail.com> wrote:
1. easy_remove!
2. Various utilities to provide query package management. - easy_install --list (list files installed)
Implementing is easier said than done, and I think you got that idea from the lack of response from folks...
I don't see why this should be all that difficult to implement. I work with the OpenPKG portable package management system, an RPM based system that exists independently of the underlying systems' packaging/software management, and it is not difficult to define procedures that cleanly management package removal and the associated dependencies. On the other hand, when building packages, I never want the build to be affected by processes that go to the Internet to pick up pieces that are thought to be out of date -- which is why I am not comfortable with much of the easy_install, setuptools philosophy. After almost 20 years of working primarily with perl, I found one of the big advantages of python was the lack of magic. While magic can be used to advantage by people like Damian Conway, author of Objective Perl, I prefer things that are reaily understood, and not subject to unexpected behavior. Bill -- INTERNET: bill@celestial.com Bill Campbell; Celestial Software LLC URL: http://www.celestial.com/ PO Box 820; 6641 E. Mercer Way Voice: (206) 236-1676 Mercer Island, WA 98040-0820 Fax: (206) 232-9186 Skype: jwccsllc (206) 855-5792 The end move in politics is always to pick up a gun. -- Buckminster Fuller
Bill Campbell wrote:
On Sun, Apr 12, 2009, Garrett Cooper wrote:
On Tue, Apr 7, 2009 at 8:05 AM, Neal Becker <ndbecker2@gmail.com> wrote:
1. easy_remove!
2. Various utilities to provide query package management. - easy_install --list (list files installed)
Implementing is easier said than done, and I think you got that idea from the lack of response from folks...
I don't see why this should be all that difficult to implement.
In part because different people want different things from the packaging, with often conflicting goals. Those conflicts increase pretty quickly when you take into account different platforms/type of development (desktop apps vs "libraries" vs webapp vs etc...). The "cross-platformness" alone, with the underlying philosophical differences on how to do deployment (bundling vs backward compatible dependencies, etc...) is quite hard to manage. David
David Cournapeau wrote:
Bill Campbell wrote:
On Sun, Apr 12, 2009, Garrett Cooper wrote:
On Tue, Apr 7, 2009 at 8:05 AM, Neal Becker <ndbecker2@gmail.com> wrote:
1. easy_remove!
2. Various utilities to provide query package management. - easy_install --list (list files installed)
Implementing is easier said than done, and I think you got that idea from the lack of response from folks...
I don't see why this should be all that difficult to implement.
In part because different people want different things from the packaging, with often conflicting goals. Those conflicts increase pretty quickly when you take into account different platforms/type of development (desktop apps vs "libraries" vs webapp vs etc...). The "cross-platformness" alone, with the underlying philosophical differences on how to do deployment (bundling vs backward compatible dependencies, etc...) is quite hard to manage.
The issue I need to address is to cooperate with other packaging systems. I'm using Fedora, which is rpm/yum based. A new python module is announced, I'd like to easy_install it. The official fedora package may be delayed by weeks. So I easy_install. But when the fedora update comes, they may conflict. For example, scons from fedora will place things in /usr/lib/scons, not the same as easy_install. easy_install will modify easy-install.pth. Nothing will clean it. So, there is a real need for easy_uninstall.
Hi Neal, Neal Becker wrote:
I'm using Fedora, which is rpm/yum based. A new python module is announced, I'd like to easy_install it. The official fedora package may be delayed by weeks. So I easy_install. But when the fedora update comes, they may conflict. For example, scons from fedora will place things in /usr/lib/scons, not the same as easy_install.
In that case, there is an easy way to fix this: do not install anything in /usr. You should *never* install anything in /usr, because it is considered owned by the system packager. Either you install it in /usr/local (if you want to keep things installed system-wide), or somewhere where you can write as a unprivileged user.
Nothing will clean it. So, there is a real need for easy_uninstall.
I did not want to imply that it was not a useful feature - I think it is a very useful feature (I dream of the day when I won't have to say "please remove the installed directory before installing an updated numpy checkout" :) ). It is just much harder to do reliably than what some people think, in part because there are now so many ways to install things in python (distutils, setuptools, pip, yolk, etc...), with different side-effects on installation. cheers, David
On Apr 14, 2009, at 6:56 AM, Neal Becker wrote:
The issue I need to address is to cooperate with other packaging systems. I'm using Fedora, which is rpm/yum based. A new python module is announced, I'd like to easy_install it. The official fedora package may be delayed by weeks. So I easy_install. But when the fedora update comes, they may conflict. For example, scons from fedora will place things in /usr/lib/scons, not the same as easy_install. easy_install will modify easy-install.pth. Nothing will clean it. So, there is a real need for easy_uninstall.
GNU stow is great for this kind of thing. If the New Distutils only writes new files and directories on installation (i.e. it does not need to *change* an existing file, the way the current easy_install has to change the contents of easy_install.pth), then it will be compatible with GNU stow, which will give me the best uninstall I could want. (For one thing, because I can use the same tool -- GNU stow -- to install and uninstall any software package, regardless of what programming language it is written in). Another option would be if you have a sufficiently automatic "bdist_rpm" feature with which you can easily produce .rpm files for your Python packages ("distributions"). Regards, Zooko
Stow (and encap) are great little nice tools but hardly they fit the rpm-linux ecosystem. A typical situation stow/encap cannot handle is when there're two library versions installed (*.so) and the related headers: in this case rpm can handle this situation where stow/encap doesn't help very much. Regards, Antonio On Tue, Apr 14, 2009 at 7:45 PM, zooko <zooko@zooko.com> wrote:
On Apr 14, 2009, at 6:56 AM, Neal Becker wrote:
The issue I need to address is to cooperate with other packaging systems. I'm using Fedora, which is rpm/yum based. A new python module is announced, I'd like to easy_install it. The official fedora package may be delayed by weeks. So I easy_install. But when the fedora update comes, they may conflict. For example, scons from fedora will place things in /usr/lib/scons, not the same as easy_install. easy_install will modify easy-install.pth. Nothing will clean it. So, there is a real need for easy_uninstall.
GNU stow is great for this kind of thing. If the New Distutils only writes new files and directories on installation (i.e. it does not need to *change* an existing file, the way the current easy_install has to change the contents of easy_install.pth), then it will be compatible with GNU stow, which will give me the best uninstall I could want. (For one thing, because I can use the same tool -- GNU stow -- to install and uninstall any software package, regardless of what programming language it is written in).
Another option would be if you have a sufficiently automatic "bdist_rpm" feature with which you can easily produce .rpm files for your Python packages ("distributions").
Regards,
Zooko
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
zooko wrote:
On Apr 14, 2009, at 6:56 AM, Neal Becker wrote:
The issue I need to address is to cooperate with other packaging systems. I'm using Fedora, which is rpm/yum based. A new python module is announced, I'd like to easy_install it. The official fedora package may be delayed by weeks. So I easy_install. But when the fedora update comes, they may conflict. For example, scons from fedora will place things in /usr/lib/scons, not the same as easy_install. easy_install will modify easy-install.pth. Nothing will clean it. So, there is a real need for easy_uninstall.
GNU stow is great for this kind of thing. If the New Distutils only writes new files and directories on installation (i.e. it does not need to *change* an existing file, the way the current easy_install has to change the contents of easy_install.pth), then it will be compatible with GNU stow, which will give me the best uninstall I could want. (For one thing, because I can use the same tool -- GNU stow -- to install and uninstall any software package, regardless of what programming language it is written in).
That's a good point. For many uses, unix/linux systems have moved from trying to have various packages modify a file, to having a directory where each package installs a file. Much easier to maintain. /usr/lib/python-xxx/site-packages/easy_install.d would be a good choice.
Just a GUI installer to make it easy.... Hopefully I can finish off my Python Package Manager program sometime soon and offer that for inclusion. I think I am about four weeks away at this rate... for an initial release.. David
The uninstaller -m option, doesn't seem to want to work for me. I haven't so far been able to get it to uninstall any packages. David
At 09:43 PM 4/21/2009 -0400, David Lyon wrote:
The uninstaller -m option, doesn't seem to want to work for me.
I haven't so far been able to get it to uninstall any packages.
That's not an uninstall option; it simply ensures that the package is no longer listed in easy-install.pth file. You must manually remove the .egg file or directory at present.
On Tue, 21 Apr 2009 23:02:54 -0400, "P.J. Eby" <pje@telecommunity.com> wrote:
At 09:43 PM 4/21/2009 -0400, David Lyon wrote:
The uninstaller -m option, doesn't seem to want to work for me.
I haven't so far been able to get it to uninstall any packages.
That's not an uninstall option; it simply ensures that the package is no longer listed in easy-install.pth file. You must manually remove the .egg file or directory at present.
Oh ok... That doesn't seem so hard.... I will try to implement that... Thank you for your assistance.. David
At 11:50 PM 4/21/2009 -0400, David Lyon wrote:
On Tue, 21 Apr 2009 23:02:54 -0400, "P.J. Eby" <pje@telecommunity.com> wrote:
At 09:43 PM 4/21/2009 -0400, David Lyon wrote:
The uninstaller -m option, doesn't seem to want to work for me.
I haven't so far been able to get it to uninstall any packages.
That's not an uninstall option; it simply ensures that the package is no longer listed in easy-install.pth file. You must manually remove the .egg file or directory at present.
Oh ok...
That doesn't seem so hard....
I will try to implement that...
If you're implementing an uninstall using easy_install, you probably also want to use -N and -x, to prevent dependencies and scripts from being reinstalled. You may also want to check what scripts a package provides, and uninstall those as well.
The issue I need to address is to cooperate with other packaging systems. I'm using Fedora, which is rpm/yum based. A new python module is announced, I'd like to easy_install it. The official fedora package may be delayed by weeks. So I easy_install. But when the fedora update comes, they may conflict.
Just as a FYI, yolk (http://tools.assembla.com/yolk/) has a plugin system to search for Python packages installed by other tools than distutils/setuptools. For example it bundles "yolk-portage", that shows if a package was installed by Gentoo's Portage. http://tools.assembla.com/yolk/browser/trunk/examples/plugins Cheers, Jannis
On Sun, Apr 12, 2009 at 09:56:19PM -0700, Bill Campbell wrote:
On Sun, Apr 12, 2009, Garrett Cooper wrote:
On Tue, Apr 7, 2009 at 8:05 AM, Neal Becker <ndbecker2@gmail.com> wrote:
1. easy_remove!
2. Various utilities to provide query package management. - easy_install --list (list files installed)
Implementing is easier said than done, and I think you got that idea from the lack of response from folks...
I don't see why this should be all that difficult to implement.
Please do not hesitate to send patches. ;) Marius Gedminas -- For vi emulation of emacs, just type ":sh emacs" (without the quotes).
For people interested in uninstall, you might want to check out this branch of pip: http://bitbucket.org/carljm/pip-uninstall/overview/ It only uninstalls things pip installed (because pip is keeping a record of installed files, which is used for the uninstallation). On Tue, Apr 7, 2009 at 10:05 AM, Neal Becker <ndbecker2@gmail.com> wrote:
1. easy_remove!
2. Various utilities to provide query package management. - easy_install --list (list files installed)
-- Ian Bicking | http://blog.ianbicking.org
Neal Becker <ndbecker2@gmail.com> writes:
1. easy_remove!
2. Various utilities to provide query package management. - easy_install --list (list files installed)
Support for installations that differentiate between `--prefix` and `--exec-prefix` on configure, i.e. as with all Python installations most header files are in the directory
"%s/include/python%s" % (sys.prefix, sys.version[:3])
But `pyconfig.h` is found in
"%s/include/python%s" % (sys.exec_prefix, sys.version[:3])
And for installation, modules should go to
"%s/lib/python%s/site-packages" % (sys.prefix, sys.version[:3])
But C extensions to
"%s/lib/python%s/site-packages" % (sys.exec_prefix, sys.version[:3])
Kind regards Berthold Höllmann -- Germanischer Lloyd AG CAE Development Vorsetzen 35 20459 Hamburg Phone: +49(0)40 36149-7374 Fax: +49(0)40 36149-7320 e-mail: berthold.hoellmann@gl-group.com Internet: http://www.gl-group.com
participants (12)
-
Antonio Cavallo -
Berthold "Höllmann" -
Bill Campbell -
David Cournapeau -
David Lyon -
Garrett Cooper -
Ian Bicking -
Jannis Leidel -
Marius Gedminas -
Neal Becker -
P.J. Eby -
zooko