Eric Smith wrote:
This discussion probably belongs on the distutils list.
Yes, the discussion should be.
Except that distutils doesn't have very much support for doing
applets or applications. So it's logical to see why most posts which
ask the same question, often go unanswered there.
Glen wrote:
So let's further say that the .zip file was named .py, instead, but was
a .zip internally.
So this cures the icon too, maybe you realized that.
It takes it to 80% cured.
Being the purist that I am I still long for the day when I
can see a python package in my file manager with
On 27/01/2010 11:21, Michael Foord wrote:
.. If a Python programmer wants
to create an application that is properly 'installed' on Windows then
the *right* thing to do is to create an installer - and that uses
infrastructure not provided by a language, but that is built into
Windows. Tools
Nick wrote:
The only one thing I have to say about that is that it makes
embedding of .py files recursive.
No it doesn't. The mechanisms involved for processing the top-level
zipfile and those for processing the .py text files within that zipfile
are completely different.
Well, if it has
Hi Nick,
I believe you're confused about what distutils is for.
Tell me..
It generates
platform independent metadata that can be used to create platform
specific installers. It also generates some platform independent Python
specific installation formats that are useful for developers, but
On 27/01/2010 13:04, Michael Foord wrote:
Installers aren't built into windows.
The infrastructure for building and using msi installers are part of
Windows and the Windows development environment. For example:
http://msdn.microsoft.com/en-us/library/aa370834%28VS.85%29.aspx
Glen wrote:
So let's say that the .zip file was dropped onto the Desktop or start
menu. It would have an icon, then.
It would have an icon. But nothing to identify it as a python
application.
One problem is that in many places, users are trained specifically
under windows to *never* run
Glen wrote:
So let's further say that the .zip file was named .py, instead, but was
a .zip internally.
The only one thing I have to say about that is that it makes
embedding of .py files recursive.
So, it begs the question How many times can you embed a .py
within a .py?
And then; How do you
Nick Coghlan:
I'd like to see Python 3+ be more suitable for full distributable
applications over 2.X and earlier.
Out of curiousity, have you tried experimenting with the zipfile
execution capabilities in 2.6/3.1? A major part of that was to make
multi-file Python applications nearly as
At 03:15 PM 1/26/2010 +1100, David Lyon wrote:
With all due respect, that process is a bit like a black magic
approach. Maybe the capability is there, but it isn't very well
documented and it isn't obvious.
I don't see what's so hard about:
1. Zip up your application in myapp.zip
On Tue, Jan 26, 2010 at 06:27, David Lyon david.l...@pythontest.org
wrote:
Secondly, I never knew about it.
Why did you say the process was like black magic when you didn't know
about it?
Is this a distutils option?
No, it's new in Python 2.6, which Nick Coghlan clearly stated
Hi Barry,
That looks very interesting...
So does that mean we could update the stdlib for a given
python version using this ?
David
I've just updated the Launchpad mirrors for the 4 active Python branches,
trunk, py3k, 2.6, and 3.1. These used to mirror the defunct Bazaar
branches
on
On Jan 20, 2010, at 10:16 AM, Barry wrote:
So does that mean we could update the stdlib for a given
python version using this ?
In a sense, yes (if I understand your question correctly).
Yeah, it just needs an implementation.
The one thing I am unsure about, mostly because I have not
On Tue, Jan 19, 2010 at 7:51 PM, Jesse Noller wrote:
Python 3 is still modularized, still has a standard library, etc. If
you're really interested in helping with the standard library, get on
stdlib-sig, and get ready to write code and PEPs.
Thank you for your direction to move these items
On Jan 19, 2010, at 08:09 PM, Barry Warsaw wrote:
I'd be surprised if any of the big 3 DVCS developers would actually /want/
their stuff in the stdlib.
If they ask, they'll get told they're motorbike-shedding. It's better
if their users ask. So here I am as a user doing things the 'right'
David Lyon david.l...@pythontest.org writes:
Being honest, if wonderful libraries like Sphinx and Mercurial and Git
and BZR can't make it into the stdlib, then there is no hope for even
newer code to get in there.
Those are applications, not libraries. Applications don't belong
Matthieu,
I'd be happy to see bzr and mercurial and git all made it together
into the stdlib for python 3. That would give a superb updating
mechanism for python that would propel python well beyond
the dinosaur badlands of CPAN and other languages.
I think there are several points that
On Wed, 13 Jan 2010 10:51:14 -0800, Guido van Rossum gu...@python.org
wrote:
Please mail me topics you'd like to hear me talk about in my keynote
at PyCon this year.
As a typical (but perphaps more vocal) python developer I would
like to hear things that might aspire me and others to move to
Nick wrote:
This has nothing to do with pushing 3.x, but all with managing
available manpower and still providing quality software.
Python 3.x needs more carrots.
As Guido has said a few times, the gains are far greater for *new*
Python developers than they are for existing ones.
Well
Hi Martin,
Of course, the less active fraction of Python contributors may not
notice, since they just chose to not contribute (which, of course,
is fine). However, asking me to work twice as much as I want to
on the project to keep two branches alive is just unfair.
Totally true. Actually
Antoine writes:
As someone who experiences the difference almost every day, I can say 3.x
definitely has enough carrots for me. The simple fact that I will be able
to
raise exceptions with non-ASCII error messages without having to
workaround a
hopelessly broken conversion/reporting logic
Hi Martin,
... but in the long run, starting now will have saved you a lot of
pressure in the long run, and stop users from switching away from
your packages because of lack of Python 3 support.
In a production situation it works the other way around. If there's
an application that requires
Hi Ian,
The only workable workflow I've seen people propose for maintaining a
single
codebase with compatibility across both 2 and 3 is to use such tricks,
with
aliases to suppress some 2to3 updates when they are inappropriate, so that
you can run 2to3 on install and have a single
Hi,
I think we've reached a consensus on those two PEPs.
Although, there's one last point that was forgotten in the discussions
: I've introduced rc in the pre-releases markers, so PEP 386 is
compatible with Python's own version scheme. rc comes right after
c in the sorting. It's slightly
On Mon, Dec 28, 2009 at 1:15 AM, Tarek Ziade wrote:
This new operator removes the ambiguity the original proposal had,
without making it more
complex for common use cases. So if you dislike it, you will need to
propose something
else that also fixes the ambiguity we had.
Ok.
Hi Martin, Happy New Year,
Requires-Dist: pywin32 (1.0); sys.platform == 'win32'
Requires-Dist: [Windows] pywin32 1.0+
That's simpler, shorter, and less ambiguous. Easier to
parse for package managers.
Don't you want the PEP to complete? Why this bike-shedding?
Well, I'm just helping
Hi Stephen,
BTW, *all* of the Python applications I really care about make a point
of specifying a range of versions they work with (or bundle a
particular version).
Yes, well that was my point exactly.
If opinion is against commas, then we can take them out.
That would give us something
Hi Len,
Another penny dropped when it comes to version specs.
Pennies are good. They build value.
With examples being:
Requires-Python: [2.5.2:3]; [3.1:]
What about going even more simple...
Requires-Python: 2.5..3 3.1..
If we use double-dots to replace colons, the ..
will translate
On Mon, 28 Dec 2009 10:42:20 +0100, Martin v. Löwis mar...@v.loewis.de
wrote:
On distutils-sig, a vocal fraction seems to think otherwise. From my
short interaction there, I now think that comparison operators are
indeed hard to use, and that the concept of a half-open interval,
and how you
On Mon, 28 Dec 2009 23:07:32 +, Michael Foord
fuzzy...@voidspace.org.uk wrote:
Requires-Python: 2.5:2.7
Specifies a range of python versions.
So this would work for Python 2.7 but *not* 2.7.1? Or does 2.7
implicitly mean a range of all Python 2.7 versions?
Yes. 2.7 would mean
On Mon, 28 Dec 2009 23:21:54 + (UTC), Antoine Pitrou
solip...@pitrou.net wrote:
Requires-Python: 2.5:2.7
Why not drop ranges as well as operators and simply use commas?
The above would be rewritten as:
Requires-Python: 2.5, 2.6, 2.7
Firstly, I find your notation proposition to be
On Mon, 28 Dec 2009 18:55:17 -0500, R. David Murray
rdmur...@bitdance.com wrote:
What about specifying that the package works only with, say, 2.6.2 or
earlier (because of some problem introduced by 2.6.3)? That could get
pretty darn verbose. (Also remember we aren't just talking about the
On Tue, 29 Dec 2009 12:00:50 +1100, Ben Finney ben+pyt...@benfinney.id.au
wrote:
The dependency declarations are *not* Python language syntax, and there
is no need to consider Python language syntax in defining them.
Well I don't know how you can say that if it is python developers
to which
On Fri, Dec 25, 2009 at 8:33 AM, Nick Coghlan ncogh...@gmail.com wrote:
Martin v. Löwis wrote:
FYI we have introduced a range operator, so one may define a range of
versions.
This is useful for instance to write:
Requires-Python: ~=2.5
Which means: requires any version of Python 2.5.x.
No application developer will quickly figure out what a tilde means.
Maybe
it means 'roughly', but it requires too much thought and is ambiguous.
2.5
is not roughly 2.5.2. It is the same exactly.
Before we had : Requires-Python: 2.5, 2.6
That made much more sense. It was simple and
Instead, the default should be â==â. That is, âRequires-Python: 3â
should be equivalent to âRequires-Python: ==3â; and only â3â or
â3.0â or
â3.0.0â etc. will match. I maintain that is what most people will
expect
on seeing that syntax.
If a less strict range is
Tarek Ziadé ziade.tarek at gmail.com writes:
An implicit range operator is simpler indeed, and achieves the same goal.
Meaning that =2.5 for example, will be translated to =2.5.x as well.
With respect, it's not a very common use case for a developer to
say that package needs a python
david.l...@preisshare.net writes:
With respect, it's not a very common use case for a developer to
say that package needs a python interpretor 'older' than 2.5.
Of course it is. I don't claim it is the majority of cases out there,
but stable versions of many of the packages I use will
Martin,
As an application developer, I really stand with Tarek here.
On Wed, 23 Dec 2009 20:07:30 +0100, Tarek Ziadé ziade.ta...@gmail.com
wrote:
2009/12/23 Martin v. Löwis mar...@v.loewis.de:
I think we want something stronger than that since they were not really
used by
the community and
On Thu, 24 Dec 2009 10:31:09 +0900, Stephen J. Turnbull
step...@xemacs.org wrote:
Martin's point is that the PEP process doesn't *have* reference
implementations. It has *sample* implementations. It may be useful
to refer to a sample implementation as an example..
Fair enough. But otoh,
On Wed, 16 Dec 2009 21:21:01 +1000, Nick Coghlan ncogh...@gmail.com
wrote:
.. we mostly leave that to the py2exe/py2app + native installer
developers of the world. There are a *lot* of thorny issues in getting
installers fully in accordance with OS developer guidelines, which is
why we tend
On Thu, 17 Dec 2009 12:18:00 +0900, Stephen J. Turnbull
step...@xemacs.org wrote:
.. because all these things are already
needed and already being done to some degree in some
organisations. There's already the libraries on pypi for
most of this anyway.
...
There clearly is no
On Tue, 15 Dec 2009 09:32:55 +, Floris Bruynooghe
floris.bruynoo...@gmail.com wrote:
If I write a shared library under C I am expected to install it under
one of the default locations if I don't want to require people to have
to tweak things before they can use it. I see no difference
Hi Tarek,
Is there anything in this proposal for windows developers ?
Just that I can't see anything that would help us...
For me, the terminology isn't anything a windows developer could
really understand. It presumes that the developer understands the
python implementation. A developer might
On Tue, 15 Dec 2009 14:40:56 +1100, Mark Hammond skippy.hamm...@gmail.com
wrote:
I think it is fine. If you are really looking for properties specific
to the operating system (eg, the location of the start menu, desktop,
appdata folders etc)
But under windows, an application developer
On Mon, 14 Dec 2009 23:58:08 +0100, Tarek Ziadé ziade.ta...@gmail.com
wrote:
Yes that's one point someone raised (can't recall who) and the idea was
to
have a separate top directory for user dirs, that would start with the
name
of the implementation:
so for Windows:
~/Python/Python26/..
On Tue, 15 Dec 2009 15:05:18 +1100, Mark Hammond
mhamm...@skippinet.com.au
wrote:
But under windows, an application developer might (as in probably
would) like to install an application in \Program Files\someapp
rather than hidden in the bowels of the python interpretor.
I agree - but in
On Tue, 15 Dec 2009 15:24:36 +1100, Mark Hammond
mhamm...@skippinet.com.au
wrote:
But under windows, an application developer might (as in probably
would) like to install an application in \Program Files\someapp
rather than hidden in the bowels of the python interpretor.
...
I'm missing your
On Fri, 13 Nov 2009 00:44:30 +0100, Xavier Morel catch-...@masklinn.net
wrote:
If pypi one day has a CPAN-style buildbot farm allowing it to test the
package on any platform under the sun, that can be included, the tests
can
be included as well but given the number of testing solutions (and
Hi All,
What do people think about this idea? I've actually started writing
something to try to to do this and create sn automated scoring system
for the packages on pypi.
It was started last week based on Guido's comments on the distutils
mailing list.
Why not rate ( or auto-rate) packages on
On Fri, 13 Nov 2009 01:27:47 +0100, Martin v. Löwis mar...@v.loewis.de
wrote:
Not sure; you would have to ask Grig. Apparently, there is a service
running somewhere that computes cheesecake data for PyPI packages;
it also sends them to PyPI. People have expressed to concerns that any
kind of
On Thu, 5 Nov 2009 11:35:41 +0100, Tarek Ziadé ziade.ta...@gmail.com
wrote:
PEP 376 is working on a default, unified, *installation* format, that
tries to gather the good ideas of Pip, Setuptools etc.. and propose a
unified format for our site-packages. This new standard will come with
APIs in
submission... David
Lyon
o [Distutils] Alternate static metadata PEP submission...
Floris Bruynooghe
+ [Distutils] Alternate static metadata PEP submission...
Georg Brandl
+ [Distutils] Alternate static metadata PEP submission...
David Lyon
Tarek,
Your proposal is a partial alternative to PEP 390, and is a quite
interesting work to dig in, and the SIG is discussing it,
but a very important point about it is that it does a lot more. It's a
new *building* system on its own, and does not limit itself to
describing metadata
On Wed, 4 Nov 2009 13:29:35 +0100, Tarek Ziadé ziade.ta...@gmail.com
wrote:
I've started to refactor the code in a module I have called
sysconfig, reusing distutils/sysconfig, distutils/command/install
and site code.
This sysconfig module should provide at the end very useful APIs to
query
On Wed, 4 Nov 2009 17:40:35 -0500, Fred Drake fdr...@acm.org wrote:
The packaging story is in such bad shape that it needs the work
regardless, and keeping it to Python 3 would significantly reduce the
set of potential volunteers.
Well I guess that is a 'marketing decision'. Not a coding
On Thu, 22 Oct 2009 10:20:03 + (UTC), Antoine Pitrou
solip...@pitrou.net wrote:
(*) Remember, however, that Tarek and work on Distribute, and also on
bringing pieces of setuptools/Distribute functionality into distutils.
But if that's the case then why not work on any third party tool..?
Hi All,
I started out some time ago and wrote a Python Package Manager
with wxpython. It was an interesting learning experience for
me. I was new to python.
Some have pointed out that using wx was not a good idea for
a tool to go into all the python distributions. Because it
required the
On Wed, 21 Oct 2009 17:56:57 -0700, Brett Cannon br...@python.org wrote:
but I don't see why python-dev should have input on that sort of thing.
python-dev is the only place where we could get a change to the
installation
binary release. We'd need a change and the addition of a program
On Wed, 21 Oct 2009 18:38:26 -0700, Brett Cannon br...@python.org wrote:
But that assumes you can get your tool into the stdlib.
No I'm not assuming that I can. I am actually assuming that I cannot..
So lets move forward..
It would have been
better to phrase the question as is there
On Tue, 20 Oct 2009 21:49:42 +0100, Paul Moore p.f.mo...@gmail.com wrote:
Can I repeat that in big letters? The key is a SINGLE DISTRIBUTION
FORMAT.
ok - but that pretty much exists..
If you can persuade everyone to accept a format which ignores clearly
stated user requirements, go for it.
On Fri, 09 Oct 2009 17:49:23 +0100, Michael Foord
I wonder if it is going to be possible to make this compatible with the
upcoming distutils package management 'stuff' (querying for installed
packages, uninstallation etc) since installation/uninstallation goes
through the Windows system
On Thu, 8 Oct 2009 21:41:21 + (UTC), Antoine Pitrou
solip...@pitrou.net wrote:
I think it's quite trivial actually. Since everybody agrees (except
perhaps
PJE)
that Distribute should replace setuptools, the word will spread and
trickle
quite quickly in the various layers of the community.
On Thu, 08 Oct 2009 09:35:57 +0200, M.-A. Lemburg m...@egenix.com wrote:
One could say that much of the setuptools cloud came about because of
the lack of the queryable download url. Setuptools does a lot of work
here to 'work-around' the ommission on pypi of a package download url.
I think
On Tue, 06 Oct 2009 16:45:29 +0100, Chris Withers ch...@simplistix.co.uk
wrote:
Well yeah, and the only sane way I can think to handle this is to have a
metadata file that gets uploaded with each distribution that covers all
these things (and the other things that other people need) and then
On Tue, 06 Oct 2009 13:52:34 -0400, P.J. Eby p...@telecommunity.com
wrote:
Btw, every couple years or so I've sent out a call on the
distutils-SIG to try to get consensus on a format for the platform
tag information used by setuptools. (The first time was before
easy_install even existed.)
On Tue, 22 Sep 2009 22:39:04 -0700, Brett Cannon br...@python.org wrote:
I don't think anyone on python-dev thought that it was exclusively
Tarek's
idea or necessarily even mostly his.
Actually, he originally argued against it, but that is irrelevant.
I'm happy that he's come around and
On Wed, 23 Sep 2009 09:49:16 +0200, M.-A. Lemburg m...@egenix.com wrote:
While it's a good idea to put up some form of meta-data
into an index, I wonder why you are using setup.cfg
for this.
setup.cfg has traditionally been used to configure distutils,
not to define meta-data. As such you
On Wed, 23 Sep 2009 15:13:55 -, exar...@twistedmatrix.com wrote:
Quite a few years of experience with a distributed team of build slave
managers has shown me that by far the most reliable way to keep slaves
online is to have them managed by a dedicated team. This team doesn't
need to
Tarek,
Are you claiming this as your own work and ideas?
Given:
http://mail.python.org/pipermail/distutils-sig/2009-August/012998.html
Regards
David
On Tue, 22 Sep 2009 15:21:06 +0200, Tarek Ziadé ziade.ta...@gmail.com
wrote:
Hello
Here's a wrapup of the Distutils-SIG discussion
we
Hello Guido,
Isn't it clear from Tarek's email that he is summarizing
distutils-sig?
Well, I'm new to this. Summarising is a word that could be
certainly applied.
Isn't it odd that you ask this question pointing to
your own message?
It's not odd at all. When I see my ideas, which
Hi Tarek,
What is needed is to remove/refactor the hardcoding of paths that
currently exists within distutils and replace it with the ability to
override the defaults via configuration files. (distutils.cfg?)
If there's one thing that's certain for the future, its that
python will go onto more
On Wed, 29 Jul 2009 10:56:20 +1000, Nick Coghlan ncogh...@gmail.com
wrote:
The words eggs brings with it a whole lot more baggage than just the
sum of the technical parts in the language core that support them
(primarily distutils and zipimport).
Well, in this case, (talking metaphorically)
On Tue, 28 Jul 2009 07:55:11 +0200, Martin v. Löwis mar...@v.loewis.de
wrote:
Yes, eggs have the same problem. That's one of the reasons they
don't get integrated into Python.
Yes but egg_info is included in python...
and the egg is not
Hence, what goes in and what doesn't isn't always
On Tue, 28 Jul 2009 11:50:00 +0100, Paul Moore p.f.mo...@gmail.com wrote:
egg_info data is in to allow standard (setup.py install and hence OS
package manager managed) packages to provide metadata in a
discoverable way. Using a format that is (reasonably) compatible with
setuptools is simply a
On Mon, 27 Jul 2009 11:18:25 +0900, Stephen J. Turnbull
step...@xemacs.org wrote:
[1] on
my part) and sysadmin goals (something that works and plays nicely
with the rest of the system).
pythonpkgmgr seems entirely oblivious to the latter issue, and not
particularly compatible with the way
On Sun, 26 Jul 2009 17:23:59 +0100, Michael Foord
fuzzy...@voidspace.org.uk wrote:
It would be great to have a decent visual package manager for Python.
Hopefully one day we'll have one - haha
It needs to be built on top of the work that Tarek is doing with
distutils (and be compatible
On Mon, 27 Jul 2009 19:29:14 +0900, David Cournapeau courn...@gmail.com
wrote:
My only point is that Windows ain't no embedded system. It's not
short on memory or disk space. If a package manager is 5 megabytes
extra say, with it's libraries.. what's the extra download time on
that ? compared
On Mon, 27 Jul 2009 20:12:54 +0900, Stephen J. Turnbull
step...@xemacs.org wrote:
Not you; pythonpkgmgr. You've said nothing about how pythonpkgmgr is
supposed to deal with multiple installed versions of Python
Under windows it can deal with multiple versions of python. You just
go to options
On Sun, 26 Jul 2009 19:31:40 +0200, Martin v. Löwis mar...@v.loewis.de
wrote:
If they read examples, they will see import
statements, and then they have to find out how to make those work.
Does your tool help with that?
Yes. It will open the website or homepage to the project/package
in
On Sun, 26 Jul 2009 19:33:37 +0200, Martin v. Löwis mar...@v.loewis.de
wrote:
pythonpkgmgr is not so different to that. And the idea behind it is
to bring consistancy in package management across the different
platforms.
At the cost of being inconsistent within a platform.
It has the most
On Tue, 28 Jul 2009 07:12:25 +0200, Martin v. Löwis mar...@v.loewis.de
wrote:
So there are now two incompatible ways to install a package:
either with the native manager, or with pythonpkgmgr. If you install
them one way, and try to remove them the other way, you lose.
pythonpkgmgr is only a
On Sun, 26 Jul 2009 08:43:07 +0200, Martin v. Löwis mar...@v.loewis.de
wrote:
Hmm. I'm -0 on providing a tool whose only purpose is to download
files from a web server. I always use a web browser for that...
It does a lot more than that. Firstly it shows what packages you
already have installed
On Sun, 26 Jul 2009 18:05:07 +1000, Steven D'Aprano st...@pearwood.info
wrote:
But you shouldn't expect the
Python dev team to accept an unproven tool into the official library
before demonstrating both the need and the solution.
Of course... that's why I started off by asking what the
On Sat, 25 Jul 2009 16:00:13 +1000, Ben Finney ben+pyt...@benfinney.id.au
wrote:
I think you know quite well what “depend on” means in this instance,
so this is taking it to silly extremes.
haha - yes - no offence.
It was just bad humour.
Have a nice weekend
David
On Sat, 25 Jul 2009 10:28:51 +0100, Paul Moore p.f.mo...@gmail.com wrote:
??? I see no bias as you describe in the distutils enhancement work.
ok
Native applications are by definition not platform neutral. How does
your proposal help Linux users? Mac OS? Solaris?
I'm doing a Linux/Solaris
On Sat, 25 Jul 2009 12:47:21 -0400, Terry Reedy tjre...@udel.edu wrote:
The Python Package Manager can be written to work in console mode.
I think this would be best.
Haha - I'm glad somebody took this seriously... It was a sort of a joke
comment but it's a serious possibility.
I took
On Fri, 24 Jul 2009 17:54:09 +0200, Georg Brandl g.bra...@gmx.net wrote:
David Lyon schrieb:
In executable form, the Package Manager does not require wxWidgets
to be installed.
There is no dependency for this to be installed.
What does in exectuable form mean?
Compiled with py2exe
On Fri, 24 Jul 2009 17:08:32 +0100, Paul Moore p.f.mo...@gmail.com wrote:
I read this as meaning that David was proposing to ship a built
application (on Windows, bundled up with something like py2exe, I
guess) and any supporting DLLs such as the wxWindows ones would be
bundled in, but the
On Fri, 24 Jul 2009 03:23:57 +0200, Christian Heimes li...@cheimes.de
wrote:
I'm sorry to inform you that a wxWindows based solution has zero change
to get into the Python standard library ever.
Is that a personal preference or is there a software engineering reason
for this?
I wasn't
On Sat, 25 Jul 2009 10:40:52 +1000, Ben Finney ben+pyt...@benfinney.id.au
wrote:
I interpret this as expressing your intent to (eventually) have your
application included in standard Python.
It's my intention to get a Package Manager included in standard
python - yes.
I wasn't suggesting
On Sat, 25 Jul 2009 11:25:27 +1000, Ben Finney ben+pyt...@benfinney.id.au
You omit the important part: adding a new thing to Python *so long as it
doesn't depend on anything outside Python*.
I'm signing out on this silly discussion for now
Any python program is dependant on things outside
That's a document describing how to use âdistutilsâ, which is what
every
recipient of Python will already have installed.
Can I ask that you also provide a link for windows users
to my project:
http://sourceforge.net/projects/pythonpkgmgr/
That doesn't seem at all appropriate;
Raising it without at least glancing at the list archives which hold
copious amounts of virtual text on that topic is somewhat inappropriate
though :)
Well I have consulted every available expert on the distutils list to the
point where I feel 'up' with the issues at hand.
They're great
On Thu, 23 Jul 2009 18:30:58 +1000, Ben Finney ben+pyt...@benfinney.id.au
wrote:
In which case you should work to get it accepted into standard Python
*before* asking for it to be promoted in the standard Python
documentation.
I'm very interested in how I would go about doing that.
Die-hard
On Fri, 24 Jul 2009 03:23:57 +0200, Christian Heimes li...@cheimes.de
wrote:
I'm sorry to inform you that a wxWindows based solution has zero change
to get into the Python standard library ever. We are not going to add
another GUI toolkit to the core distribution.
In executable form, the
On Wed, 22 Jul 2009 10:26:59 -0400, Tres Seaver tsea...@palladion.com
wrote:
You were complaining that setuptools /
distutils wants to put files in an OS-controlled directory:
I complain about many things - so what.
I was
asking how Python was supposed to know the difference between
On Wed, 22 Jul 2009 23:22:56 +0200, M.-A. Lemburg m...@egenix.com wrote:
Maybe I've misunderstood some important detail, but how will
their change help with anything other than making their
distribution a non-standard Python installation ?
The Debian/ubuntu distribution isn't non-standard. If
Hi Greg,
I'm on the python-dev mailing list and somebody gave me a link
to a page that you have done:
http://docs.python.org/install/
Can I ask that you also provide a link for windows users
to my project:
http://sourceforge.net/projects/pythonpkgmgr/
Our project provides an alternative
On Tue, 21 Jul 2009 13:41:41 -0400, Tres Seaver tsea...@palladion.com
wrote:
The main problem imho has been that easy_install by default
has installed to /usr/lib/pythonX.X/site-packages when in
fact that really is an operating system controlled directory.
So naughty naughty to setuptools
1 - 100 of 107 matches
Mail list logo
