> 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.
P
> 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.asp
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,
> 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
> 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. T
>> 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
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
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 any
> On Tue, Jan 26, 2010 at 06:27, David Lyon
> 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 Cogh
> 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 abo
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 nearl
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 point
> "David Lyon" 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. Applic
> 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
> 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 ite
> 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 n
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 Wed, 13 Jan 2010 10:51:14 -0800, Guido van Rossum
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
python 3.
The w
> 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 on
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 lo
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. Actuall
> 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.
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 can
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 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'
> 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.
> Env
On Tue, 29 Dec 2009 12:00:50 +1100, Ben Finney
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 all this effort is targeted
On Mon, 28 Dec 2009 18:55:17 -0500, "R. David Murray"
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
> syntax for Python
On Mon, 28 Dec 2009 23:21:54 + (UTC), Antoine Pitrou
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 entirely wor
On Mon, 28 Dec 2009 23:07:32 +, Michael Foord
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 all 2.7 version
On Mon, 28 Dec 2009 10:42:20 +0100, "Martin v. Löwis"
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 can use relatio
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 transl
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
> 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 u
>> Tarek Ziadé 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 interpretor
> 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
>> 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
> On Fri, Dec 25, 2009 at 8:33 AM, Nick Coghlan 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. This oper
On Thu, 24 Dec 2009 10:31:09 +0900, "Stephen J. Turnbull"
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, asking for samp
Martin,
As an application developer, I really stand with Tarek here.
On Wed, 23 Dec 2009 20:07:30 +0100, Tarek Ziadé
wrote:
> 2009/12/23 "Martin v. Löwis" :
>>> I think we want something stronger than that since they were not really
>>> used by
>>> the community and removed and replaced by some
On Thu, 17 Dec 2009 12:18:00 +0900, "Stephen J. Turnbull"
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 interest in
On Wed, 16 Dec 2009 21:21:01 +1000, Nick Coghlan
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 to shy away from
On Tue, 15 Dec 2009 09:32:55 +, Floris Bruynooghe
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 with
> python modules or pac
On Tue, 15 Dec 2009 15:24:36 +1100, Mark Hammond
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 point
On Tue, 15 Dec 2009 15:05:18 +1100, Mark Hammond
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 that case you are tal
On Mon, 14 Dec 2009 23:58:08 +0100, Tarek Ziadé
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/..
> ~/IronPython/.
On Tue, 15 Dec 2009 14:40:56 +1100, Mark Hammond
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 might (as in probably
wou
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 Fri, 13 Nov 2009 01:27:47 +0100, "Martin v. Löwis"
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 ranking based
On Fri, 13 Nov 2009 01:14:54 +0100, "Martin v. Löwis"
wrote:
> http://pycheesecake.org/
Ok, so what is the current status on it?
David
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
h
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 00:44:30 +0100, Xavier Morel
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
coverage
> discovery as
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 fi
andl
o [Distutils] Alternate static metadata PEP submission... David
Lyon
o [Distutils] Alternate static metadata PEP submission...
Floris Bruynooghe
+ [Distutils] Alternate static metadata PEP submission...
Georg Brandl
+ [Distutils] Al
On Thu, 5 Nov 2009 11:35:41 +0100, Tarek Ziadé
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 pkgutil to be abl
On Wed, 4 Nov 2009 17:40:35 -0500, Fred Drake 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 issue.
Actually
On Wed, 4 Nov 2009 13:29:35 +0100, Tarek Ziadé
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 the current
On Thu, 22 Oct 2009 10:20:03 + (UTC), Antoine Pitrou
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..? like
pip or setupto
On Wed, 21 Oct 2009 18:38:26 -0700, Brett Cannon 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 interest in having a
On Wed, 21 Oct 2009 17:56:57 -0700, Brett Cannon 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
shortcut.
> If you want
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 externa
On Tue, 20 Oct 2009 21:49:42 +0100, Paul Moore 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. But if you can't,
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, 08 Oct 2009 09:35:57 +0200, "M.-A. Lemburg" 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 you tw
On Thu, 8 Oct 2009 21:41:21 + (UTC), Antoine Pitrou
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.
I don't think t
On Tue, 06 Oct 2009 16:45:29 +0100, Chris Withers
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 have
> the index (
On Tue, 06 Oct 2009 13:52:34 -0400, "P.J. Eby"
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.) Unfortunately,
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 t
On Wed, 23 Sep 2009 09:49:16 +0200, "M.-A. Lemburg" 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 wouldn't
On Tue, 22 Sep 2009 22:39:04 -0700, Brett Cannon 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 embraced it. Perhaps
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 T
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é
wrote:
> Hello
>
> Here's a wrapup of the Distutils-SIG discussion
> we had on the "static m
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
Hi Jan,
It's not impossible, but you have some dependencies.
If you can patch distutils within Suse, then it mightn't be so
difficult. Distutils is not much more than a file copier.
Inside distutils, a lot of the paths that you are talking
about are hardcoded.
> One, python depends on the "lib
On Wed, 29 Jul 2009 10:56:20 +1000, Nick Coghlan
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) we have the abi
On Tue, 28 Jul 2009 11:50:00 +0100, Paul Moore 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 matter of co-
On Tue, 28 Jul 2009 07:55:11 +0200, "Martin v. Löwis"
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 that rational. I'
On Tue, 28 Jul 2009 07:12:25 +0200, "Martin v. Löwis"
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 thin wrapper fo
On Sun, 26 Jul 2009 19:33:37 +0200, "Martin v. Löwis"
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 generic o
On Sun, 26 Jul 2009 19:31:40 +0200, "Martin v. Löwis"
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 quest
On Mon, 27 Jul 2009 20:12:54 +0900, "Stephen J. Turnbull"
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 and select whic
On Mon, 27 Jul 2009 19:29:14 +0900, David Cournapeau
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 to three da
On Sun, 26 Jul 2009 17:23:59 +0100, Michael Foord
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 with his Distribute fork o
On Mon, 27 Jul 2009 11:18:25 +0900, "Stephen J. Turnbull"
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 package m
On Sun, 26 Jul 2009 18:05:07 +1000, Steven D'Aprano
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 process is.
I am acc
On Sun, 26 Jul 2009 08:43:07 +0200, "Martin v. Löwis"
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 and lets you m
On Sat, 25 Jul 2009 11:42:13 +0200, "Martin v. Löwis"
wrote:
>> It's my intention to get a Package Manager included in standard
>> python - yes.
>
> In addition to the other constraints you'll have to meet for this
> to happen, you also have to wait a rather long time (several years)
> before inc
On Sat, 25 Jul 2009 12:47:21 -0400, Terry Reedy 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 it
On Sat, 25 Jul 2009 10:28:51 +0100, Paul Moore 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 version. But I find
On Sat, 25 Jul 2009 16:00:13 +1000, Ben Finney
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
___
Pyt
On Sat, 25 Jul 2009 11:25:27 +1000, Ben Finney
> 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" python. For
example an
On Sat, 25 Jul 2009 10:40:52 +1000, Ben Finney
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 including it in the standar
On Fri, 24 Jul 2009 03:23:57 +0200, Christian Heimes
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 suggesting including i
On Fri, 24 Jul 2009 17:08:32 +0100, Paul Moore 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 wxPython package wo
On Fri, 24 Jul 2009 17:54:09 +0200, Georg Brandl 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
On Fri, 24 Jul 2009 03:23:57 +0200, Christian Heimes
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 Package Manager do
On Thu, 23 Jul 2009 18:30:58 +1000, Ben Finney
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 users probably know all
> 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 pe
Hi Floris,
That's exactly how I see it and i totally agree.
My contribution is to make a Package Manager Gui that tries to be
supportive of what you describe so well.
If i have any complaint about the state of affairs it would only be that
it takes a newcomer such a long time (months) to fully u
> 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 app
1 - 100 of 111 matches
Mail list logo
