GUI for Python package Management
Hi All, I am a developer from other languages and find myself on python now. I'm wondering if anybody has objections to doing a package management gui for python. My design suggestions would be to: - use WXWidgets (cross compatability for most pythonic platforms) - provide a GUI wrapper for EasyInstall - source packages from http://pypi.python.org/pypi It seems we have most of the componentry in place. The problem seems to be that it doesn't come together in a very user friendly way at the moment that is cohesive. Can anybody/everybody flame/tell me why we shouldn't work to simplify this area of python ?
On Jan 28, 2009, at 11:11 PM, <david.lyon@preisshare.net> <david.lyon@preisshare.net
wrote:
Hi All,
I am a developer from other languages and find myself on python now.
I'm wondering if anybody has objections to doing a package management gui for python.
My design suggestions would be to:
- use WXWidgets (cross compatability for most pythonic platforms) - provide a GUI wrapper for EasyInstall - source packages from http://pypi.python.org/pypi
It seems we have most of the componentry in place. The problem seems to be that it doesn't come together in a very user friendly way at the moment that is cohesive.
Can anybody/everybody flame/tell me why we shouldn't work to simplify this area of python ?
I don't think that the missing of a gui is what is the problem today for python. Package uninstall is something that bothers some (maybe a lot) of users. Another point is to have something like webstart for java. If I understand how it works, running an application goes like this: If you open an app and it depends on another package not installed on your system java goes around and download the missing modules for you (and stores them in a relative place to the package or the user package dir) so the application can run. This would be cool for python, the problem being that there is no security to guarantee that those modules are not malicious in any way... That is it, I would not opose to have a gui to install python modules, but I couldn't care less for one. There are a lot more pressing matters in the distutils/setuptools part of the python env than a gui. -- Leonardo Santagada santagada at gmail.com
Hi Leonardo,
I don't think that the missing of a gui is what is the problem today for python. Package uninstall is something that bothers some (maybe a lot) of users.
Yeah. Me too. Possibly made easier by having a GUI.
Another point is to have something like webstart for java. If I understand how it works, running an application goes like this: If you open an app and it depends on another package not installed on your system java goes around and download the missing modules for you (and stores them in a relative place to the package or the user package dir) so the application can run. This would be cool for python, the problem being that there is no security to guarantee that those modules are not malicious in any way...
I agree with that strongly. In my travels, I have just come across PyPI. Which seems like a sort of CPAN. It seems to have a good base of packages. I am not sure if that is competitive to distutils or not, but would like to know. Following is some code I could incorporate into the GUI: PyPI's XML-RPC methods Example usage: >>> import xmlrpclib >>> server = xmlrpclib.Server('http://pypi.python.org/pypi') >>> server.package_releases('roundup') ['1.1.2'] >>> server.search('roundup', '1.1.2')
That is it, I would not opose to have a gui to install python modules, but I couldn't care less for one. There are a lot more pressing matters in the distutils/setuptools part of the python env than a gui.
hmm... I am kindof the reverse. :-) Not keen to work on the code behind the scenes only keen to have some gui. Hey, thanks. Very informative. Hope I can do something. David
david.lyon@preisshare.net wrote:
I don't think that the missing of a gui is what is the problem today for python. Package uninstall is something that bothers some (maybe a lot) of users.
Yeah. Me too. Possibly made easier by having a GUI.
The biggest problem is that the installer does not save the information necessary to perform the uninstall. A secondary problem is accounting for dependencies between packages. A GUI does not help either of these problems. If you can implement an uninstall in the GUI, you can implement it from the command line.
Another point is to have something like webstart for java. If I understand how it works, running an application goes like this: If you open an app and it depends on another package not installed on your system java goes around and download the missing modules for you (and stores them in a relative place to the package or the user package dir) so the application can run. This would be cool for python, the problem being that there is no security to guarantee that those modules are not malicious in any way...
I agree with that strongly.
I very much dislike things that automatically download and install software. An automatic installer may find a different version of a supporting package every time I install software on another machine. I keep careful track of what is installed on all my machines. If the tool automatically installs any version other than the one I specified, then the tool is working _against_ me. I don't need that. Ideally, there would be a flag that says "if you can't find something, give me an error -- do not attempt to download/install anything". But it would be helpful if it can tell me "Package xyzzy is missing, but you can get it from here:..." Mark S.
On Jan 29, 2009, at 7:01 PM, Mark Sienkiewicz wrote:
david.lyon@preisshare.net wrote:
I don't think that the missing of a gui is what is the problem today for python. Package uninstall is something that bothers some (maybe a lot) of users.
Yeah. Me too. Possibly made easier by having a GUI.
The biggest problem is that the installer does not save the information necessary to perform the uninstall. A secondary problem is accounting for dependencies between packages.
A GUI does not help either of these problems. If you can implement an uninstall in the GUI, you can implement it from the command line.
Another point is to have something like webstart for java. If I understand how it works, running an application goes like this: If you open an app and it depends on another package not installed on your system java goes around and download the missing modules for you (and stores them in a relative place to the package or the user package dir) so the application can run. This would be cool for python, the problem being that there is no security to guarantee that those modules are not malicious in any way...
I agree with that strongly.
I very much dislike things that automatically download and install software. An automatic installer may find a different version of a supporting package every time I install software on another machine.
if the application asks for the different version then yes it should download the version that was asked for and installed for that application. It will only find a different version each time if the application asks for it.
I keep careful track of what is installed on all my machines. If the tool automatically installs any version other than the one I specified, then the tool is working _against_ me. I don't need that.
No it is working like the application writer specified it.
Ideally, there would be a flag that says "if you can't find something, give me an error -- do not attempt to download/install anything". But it would be helpful if it can tell me "Package xyzzy is missing, but you can get it from here:..."
This I agree, it should have a way to ignore some requests or even all requests of the application that is launched, maybe even have a configuration file somewhere (or a registry key, or a plist file depending on the os) that override the default, which I think should be give the running application the version that it specifies (standard packaging version rules apply, if it asks for package >=1.0 then any version newer than 1.0 is sufficient) But this is just a proposition that I think will never be able to work with python without security or only signed and pre approved packages on pypi.
Mark S.
-- Leonardo Santagada santagada at gmail.com
I very much dislike things that automatically download and install software. An automatic installer may find a different version of a supporting package every time I install software on another machine.
if the application asks for the different version then yes it should download the version that was asked for and installed for that application. It will only find a different version each time if the application asks for it.
Here is an example of the scenario I am trying to avoid: Suppose the package foobar asks for "xyzzy > 2.3". On machine Fred, I install foobar on Tuesday. I do not even know that foobar needs xyzzy, so unless I watch the install closely, Fred may have xyzzy 2.4 installed. On machine Barney, I install foobar on Wednesday. I do not know there was a new release of xyzzy overnight, but Barney now has xyzzy 2.5 installed. Six months from now, my user says "YOUR program is broken - it doesn't do the same thing on Fred and Barney". I figure out that it is the version of xyzzy, then decide that the correct answers come when I use 2.4. It was automatically installed, so I don't have a copy of it in my archive of source code. I try to download it, but I can only find 2.5, 2.6, and 2.7 online. What do I do? Compare with: On machine Fred, I install foobar on Tuesday, but I use --no-automatic. It says "You must have xyzzy > 2.3". I download xyzzy 2.4 to my collection of source code, install it on Fred, then install foobar. Everything works. On Wednesday, I install, on Barney, xyzzy 2.4 from my collection of source code and my own package foobar. Six months from now, my user sees that my program does the same thing on Fred and Barney.
I keep careful track of what is installed on all my machines. If the tool automatically installs any version other than the one I specified, then the tool is working _against_ me. I don't need that.
No it is working like the application writer specified it.
I agree, except for the part where you said "No". :) I think the correct description is "Yes! It is working like the application writer specified it, but it is making proper configuration control difficult."
Ideally, there would be a flag that says "if you can't find something, give me an error -- do not attempt to download/install anything". But it would be helpful if it can tell me "Package xyzzy is missing, but you can get it from here:..."
This I agree, it should have a way to ignore some requests or even all requests of the application that is launched, maybe even have a configuration file somewhere (or a registry key, or a plist file depending on the os) that override the default, which I think should be give the running application the version that it specifies (standard packaging version rules apply, if it asks for package >=1.0 then any version newer than 1.0 is sufficient)
Good point -- we need two options here: 1. do not download/install anything, just raise an error 2. use the version module XXX that I have, even though the package says it is not suitable
But this is just a proposition that I think will never be able to work with python without security or only signed and pre approved packages on pypi.
Is it really different from what setuptools already does? Do we know how CPAN handles security? Mark S.
On Jan 29, 2009, at 8:29 PM, Mark Sienkiewicz wrote:
I very much dislike things that automatically download and install software. An automatic installer may find a different version of a supporting package every time I install software on another machine.
if the application asks for the different version then yes it should download the version that was asked for and installed for that application. It will only find a different version each time if the application asks for it.
Here is an example of the scenario I am trying to avoid:
Suppose the package foobar asks for "xyzzy > 2.3".
On machine Fred, I install foobar on Tuesday. I do not even know that foobar needs xyzzy, so unless I watch the install closely, Fred may have xyzzy 2.4 installed. On machine Barney, I install foobar on Wednesday. I do not know there was a new release of xyzzy overnight, but Barney now has xyzzy 2.5 installed.
Six months from now, my user says "YOUR program is broken - it doesn't do the same thing on Fred and Barney".
I figure out that it is the version of xyzzy, then decide that the correct answers come when I use 2.4. It was automatically installed, so I don't have a copy of it in my archive of source code. I try to download it, but I can only find 2.5, 2.6, and 2.7 online.
What do I do?
Compare with:
On machine Fred, I install foobar on Tuesday, but I use --no- automatic. It says "You must have xyzzy > 2.3".
I download xyzzy 2.4 to my collection of source code, install it on Fred, then install foobar. Everything works.
On Wednesday, I install, on Barney, xyzzy 2.4 from my collection of source code and my own package foobar.
Six months from now, my user sees that my program does the same thing on Fred and Barney.
This is just one of the example of why packages should not use ">=" in vain :) But yep, it gets complex but I think there is ways around this, specially if this behavior became accepted.
I keep careful track of what is installed on all my machines. If the tool automatically installs any version other than the one I specified, then the tool is working _against_ me. I don't need that.
No it is working like the application writer specified it.
I agree, except for the part where you said "No". :)
I think the correct description is "Yes! It is working like the application writer specified it, but it is making proper configuration control difficult."
Who does configuration control? Not end users right? So I think this autoinstall method should be used the same way that webstart is used, for end users only. It will not take the place of buildout or manual installation. This is a feature to make python programs easier to run for the end user. So we can distribute python packages without having to use py2exe or anything like that.
Ideally, there would be a flag that says "if you can't find something, give me an error -- do not attempt to download/install anything". But it would be helpful if it can tell me "Package xyzzy is missing, but you can get it from here:..."
This I agree, it should have a way to ignore some requests or even all requests of the application that is launched, maybe even have a configuration file somewhere (or a registry key, or a plist file depending on the os) that override the default, which I think should be give the running application the version that it specifies (standard packaging version rules apply, if it asks for package >=1.0 then any version newer than 1.0 is sufficient)
Good point -- we need two options here:
1. do not download/install anything, just raise an error
2. use the version module XXX that I have, even though the package says it is not suitable
But this is just a proposition that I think will never be able to work with python without security or only signed and pre approved packages on pypi.
Is it really different from what setuptools already does?
Do we know how CPAN handles security?
No it is not. the difference is that you have to today easy_install an application for it to download its dependencies, it is like saying "I believe in this package dev team and so I believe they are not bring harmfull modules to my system". But well... as python doesn't have a sandbox everytime you run an application you are trusting the developer... so if this system build a virtual env for each app it runs all will be ok (as a package that the program brings will not affect the system configuration). -- Leonardo Santagada santagada at gmail.com
On Thu, 29 Jan 2009 17:29:28 -0500, Mark Sienkiewicz <sienkiew@stsci.edu> wrote:
I very much dislike things that automatically download and install software. An automatic installer may find a different version of a supporting package every time I install software on another machine.
.. ..
Here is an example of the scenario I am trying to avoid: Suppose the package foobar asks for "xyzzy > 2.3". On machine Fred, I install foobar on Tuesday. I do not even know that foobar needs xyzzy, so unless I watch the install closely, Fred may have xyzzy 2.4 installed. On machine Barney, I install foobar on Wednesday. I do not know there was a new release of xyzzy overnight, but Barney now has xyzzy 2.5 installed. Six months from now, my user says "YOUR program is broken - it doesn't do the same thing on Fred and Barney". ....
I so totally agree... I work in an IT department with dozens of machines. I am always upgrading and changing machines. It wastes so much time going and searching for dependant packages, downloading and installing them. Asking users on site to upgrade a dependent package seems to be one of the worst things to ever do from my experience. They invariably get it wrong - and blame the developer for their mistake. Maybe it is just me. What I need for myself, is a package manifest, tracking all the packages that I have installed. Then when I go set up on a new machine, I can load the manifest, and the tool will go get me all my packages. So I totally agree with your comments... that is why I am thinking that a GUI could streamline this area. David
<david.lyon@preisshare.net> writes:
What I need for myself, is a package manifest, tracking all the packages that I have installed. Then when I go set up on a new machine, I can load the manifest, and the tool will go get me all my packages.
So I totally agree with your comments... that is why I am thinking that a GUI could streamline this area.
An interface is premature if the manifest doesn't yet exist. Let's solve that problem before thinking of a GUI for it. -- \ “I got fired from my job the other day. They said my | `\ personality was weird. … That's okay, I have four more.” | _o__) —Bug-Eyed Earl, _Red Meat_ | Ben Finney
Hi Ben, On Fri, 30 Jan 2009 13:04:30 +1100, Ben Finney <ben+python@benfinney.id.au> wrote:
An interface is premature if the manifest doesn't yet exist. Let's solve that problem before thinking of a GUI for it.
From the other perspective, it is a fairly trivial task for the gui to
I can see your point there.. track what packages it has installed - through it's own configuration file and generate a manifest from that. That would save a lot of time waiting for the back-end guys to do all the hard slog behind the scenes. That is just how I see it anyway... Best Regards David
(Could you please set your name in your From field? Thanks.) <david.lyon@preisshare.net> writes:
From the other perspective, it is a fairly trivial task for the gui to track what packages it has installed - through it's own configuration file and generate a manifest from that.
You mean, have packages tracked separately depending on which program was used to install them? That seems like a recipe for madness. -- \ “Hanging one scoundrel, it appears, does not deter the next. | `\ Well, what of it? The first one is at least disposed of.” | _o__) —Henry L. Mencken | Ben Finney
Ben Finney wrote:
(Could you please set your name in your From field? Thanks.)
<david.lyon@preisshare.net> writes:
From the other perspective, it is a fairly trivial task for the gui to track what packages it has installed - through it's own configuration file and generate a manifest from that.
You mean, have packages tracked separately depending on which program was used to install them? That seems like a recipe for madness.
Agreed, manifest generation -has- to be done in the backend. Also any such tracking of what is installed has to address the use case of sandboxes into which different things are installed concurrently. And it needs to handle that some of those sandboxes are connected via wormholes to the system Python site-packages. I'm talking about the 'virtualenv' command and its command-line option whether to let the system site-packages be available as a last resort when searching for packages. And having experience with Red Hat RPMs, you also should have a tool to rebuild the registry of packages, say from .egg metadata, should the registry be corrupted. Not an easy problem at all to get right. -Jeff
On Fri, 30 Jan 2009 07:43:45 -0600, Jeff Rush <jeff@taupro.com> wrote:
You mean, have packages tracked separately depending on which program was used to install them? That seems like a recipe for madness.
Agreed, manifest generation -has- to be done in the backend.
Isn't this already been done in the backend? :-) Actually, when you install enough packages, this is where it gets crazy and it drives the average mad - from a user perspective. Some packages are installed using a windows installer (or rpm), some using 'setup.py install', some using easy_install. In other languages, you just use the one tool.. Users already know madness... :-) and have had it for some time not through anybodies fault. The discussion you guys are having about all the fixes that you can/could do is very interesting. I think you are all on the right track. Regards David
David Lyon <david.lyon@preisshare.net> writes:
In other languages, you just use the one tool..
That's misleading. In well-designed systems, you use any of a number of different *tools*, all of which use the same back-end *library interface* (which might effectively mean “the same library” or “mutliple libraries coded to the same interface”). If the only workable back-end is a single tool, then that tool effectively becomes the back-end library and people bolt on multiple tools as front-ends to it. But that seems inferior to a true reusable library that is intended for use in implementing front-end tools. -- \ “Odious ideas are not entitled to hide from criticism behind | `\ the human shield of their believers' feelings.” —Richard | _o__) Stallman | Ben Finney
Hi Ben, Well I could argue with you all day... but my wife seems to have taken that job.. Here is a screenshot of what I have done so far... On Sat, 31 Jan 2009 10:03:50 +1100, Ben Finney <ben+python@benfinney.id.au> wrote:
David Lyon <david.lyon@preisshare.net> writes:
In other languages, you just use the one tool..
That's misleading. In well-designed systems, you use any of a number of different *tools*, all of which use the same back-end *library interface* (which might effectively mean “the same library” or “mutliple libraries coded to the same interface”).
If the only workable back-end is a single tool, then that tool effectively becomes the back-end library and people bolt on multiple tools as front-ends to it. But that seems inferior to a true reusable library that is intended for use in implementing front-end tools.
David Lyon <david.lyon@preisshare.net> writes:
Here is a screenshot of what I have done so far...
Please *do not* send binary attachments, or *any* large attachment, unsolicited to a mailing list. Especially not if you're sending *antoher* copy to me personally. Instead, pop it on a free hosting site and give us a URL; then we can decide whether and when the file arrives at our computer. -- \ “All good things are cheap; all bad are very dear.” —Henry | `\ David Thoreau | _o__) | Ben Finney
Hi All, I seem to have a prototype gui of some description running based around the PyPiXmlRpc Using that code I can locate packages, but not install or download them.... (strange - incomplete api i guess) Anyway, now I need a foolproof/pre-existing way to download and install modules. This following script seems to pop up as being a good one to use: http://peak.telecommunity.com/dist/ez_setup.py One good (?) thing is that it seems to resolve package dependencies. but... my question is... is it "right" ? as far as distutils and the general python programming community is concerned? Instead of this, is there even a "right-way" or "better way"? David
At 07:57 AM 1/30/2009 -0500, David Lyon wrote:
I seem to have a prototype gui of some description running based around the PyPiXmlRpc
Using that code I can locate packages, but not install or download them.... (strange - incomplete api i guess)
Anyway, now I need a foolproof/pre-existing way to download and install modules.
This following script seems to pop up as being a good one to use:
http://peak.telecommunity.com/dist/ez_setup.py
One good (?) thing is that it seems to resolve package dependencies.
but... my question is... is it "right" ? as far as distutils and the general python programming community is concerned?
Apparently not. ;-) However, the primary complaints have to do with how the resulting packages are installed, not how they're found or obtained. And it's quite possible to use easy_install as a base for locating and retrieving packages from PyPI, based on version requirements, *without* using it as the actual installation method. See, e.g., Ian Bicking's install tool (whose name escapes me at the moment), that does this. zc.buildout wraps easy_install in a similar way, to implement still other installation policies. Using e.g. 'easy_install -e -b somedir SomePackage', will get you a somedir/somepackage directory (with 'somepackage' always in lower case) with the package's complete source code. If you then wish to install it with distutils or something else, you can then do so. (This is more or less what Ian's tool does.)
Instead of this, is there even a "right-way" or "better way"?
Not really -- hence the current huge discussions. ;-) (Which, by the way, I'm glad to see. I tried to get the same basic discussion rolling a few months back, but it didn't really go anywhere back then.)
On Fri, 30 Jan 2009 11:21:29 -0500, "P.J. Eby" <pje@telecommunity.com> wrote:
but... my question is... is it "right" ? as far as distutils and the general python programming community is concerned?
Apparently not. ;-)
So the "right" way is to download it, unpack it in a directory and then just run "python setup.py install" as we would do from the command line? Another 20 lines of code or so....
Hi all, I am pleased to announce that we have started a new python project on sourceforge. Python Package Manager pythonpkgmgr.sourceforge.net The goal is to provide a cross platform GUI tool that will vastly simplify loading and installing packages under python. - written in python - use WXWidgets for cross compatability - utilises distutils - provide a GUI wrapper for EasyInstall and pip - fetches packages from http://pypi.python.org/pypi using their XML-RPC interface. Feel free to apply to join the project and help us build the solution that we all need and deserve. Regards David Lyon
David Lyon <david.lyon@preisshare.net> writes:
The goal is to provide a cross platform GUI tool that will vastly simplify loading and installing packages under python.
Thanks for the announcement.
- written in python - use WXWidgets for cross compatability - utilises distutils - provide a GUI wrapper for EasyInstall and pip
This all sounds good.
- fetches packages from http://pypi.python.org/pypi using their XML-RPC interface.
Surely this is something that should be done by the package management library, making it available in one place for each front-end tool; not implemented in a specific front-end tool? -- \ “Nature is trying very hard to make us succeed, but nature does | `\ not depend on us. We are not the only experiment.” —Richard | _o__) Buckminster Fuller, 1978-04-30 | Ben Finney
On Mon, Feb 2, 2009 at 05:48, Ben Finney <ben+python@benfinney.id.au> wrote:
- fetches packages from http://pypi.python.org/pypi using their XML-RPC interface.
Surely this is something that should be done by the package management library, making it available in one place for each front-end tool; not implemented in a specific front-end tool?
Right, for example if you use cache/mirror. -- Sebastien Douche <sdouche@gmail.com>
On Tue, 3 Feb 2009 18:48:15 +0100, Sebastien Douche <sdouche@gmail.com> wrote:
wrote:
- fetches packages from http://pypi.python.org/pypi using their XML-RPC interface.
Surely this is something that should be done by the package management library, making it available in one place for each front-end tool; not implemented in a specific front-end tool?
Right, for example if you use cache/mirror.
From a developer perspective, what we need most is a list of packages that we have installed (a manifest?) and then a way perphaps bundle all those
I'm not sure I understand what you mean? As I work through the issues I have discovered that a number of the installation libries support this functionality. That is pip and some others. I don't think it is in setuptools yet. So I am putting provision for that functionality in the gui from the start. packages into one (file?).. and put them to our client machines in one go... At the moment, there doesn't seem to be any easy way of managing ones installed packages. ie even finding help or documentation on ones packages is quite difficult. That is what I am hoping to address. That functionality is way down the track for me too.... I'm just trying to get the real simple stuff working first..... :-) This is a screenshot so far... http://sourceforge.net/projects/pythonpkgmgr/#item3rd-2 Regards David
Hello! On Thu, Jan 29, 2009 at 6:41 AM, <david.lyon@preisshare.net> wrote:
Hi All,
I am a developer from other languages and find myself on python now.
I'm wondering if anybody has objections to doing a package management gui for python.
My design suggestions would be to:
- use WXWidgets (cross compatability for most pythonic platforms) - provide a GUI wrapper for EasyInstall - source packages from http://pypi.python.org/pypi
It seems we have most of the componentry in place. The problem seems to be that it doesn't come together in a very user friendly way at the moment that is cohesive.
Can anybody/everybody flame/tell me why we shouldn't work to simplify this area of python ?
I am one of developers working on the Python support in NetBeans project: http://wiki.netbeans.org/Python. I am working on the design of a "Egg Manager" in NetBeans, which will enable the Python developer to manage the "eggs" from NetBeans IDE itself. The manager will use 'easy_install' for the time being, via its XML-RPC interface, and will have support for user created 'virtualenv' platforms. This I am sure will be a definite value addition to the Python developers who are working with NetBeans. Coming to your question,( I am a newbie to this area), but seems like 'PyPI' is perhaps the best way to go with if anyone wants to design something related Package manager for Python and 'easy_install' will be the background working 'thread'. Just my 2-cents.. -Amit
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
-- Amit Kumar Saha http://amitksaha.blogspot.com http://amitsaha.in.googlepages.com/ *Bangalore Open Java Users Group*:http:www.bojug.in
I'd be delighted to see someone working on this. However, in my ideal world, this would be something that integrated with IDLE. I know tk is not a patch on wx, but it is an included battery. On Wed, Jan 28, 2009 at 10:11 PM, <david.lyon@preisshare.net> wrote:
Hi All,
I am a developer from other languages and find myself on python now.
I'm wondering if anybody has objections to doing a package management gui for python.
My design suggestions would be to:
- use WXWidgets (cross compatability for most pythonic platforms) - provide a GUI wrapper for EasyInstall - source packages from http://pypi.python.org/pypi
It seems we have most of the componentry in place. The problem seems to be that it doesn't come together in a very user friendly way at the moment that is cohesive.
Can anybody/everybody flame/tell me why we shouldn't work to simplify this area of python ?
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
On Thu, 29 Jan 2009 12:17:16 +0000, phil jones <interstar@gmail.com> wrote:
I'd be delighted to see someone working on this. However, in my ideal world, this would be something that integrated with IDLE. I know tk is not a patch on wx, but it is an included battery.
Thanks Phil. My skills don't extend to tk although I can assure you that I have tried :-) wx is easier for me. What I'm hoping to do is a standalone application that could be fired off just like an os package manager or ppm in perl. As good as IDLE is, not everybody uses it. I am thinking of doing something that could sit next to idle in the python program group. Take care David
participants (10)
-
Amit k. Saha -
Ben Finney -
David Lyon -
david.lyon＠preisshare.net
-
Jeff Rush -
Leonardo Santagada -
Mark Sienkiewicz -
P.J. Eby -
phil jones -
Sebastien Douche