Re: [Python-Dev] Status of packaging in 3.3

On 6/22/12 7:05 AM, Nick Coghlan wrote: .. - I reject setup.cfg, as I believe ini-style configuration files are not appropriate for a metadata format that needs to include file listings and code fragments I don't understand what's the problem is with ini-style files, as they are suitable for mu

Re: [Python-Dev] Status of packaging in 3.3

On Fri, Jun 22, 2012 at 4:25 PM, Stephen J. Turnbull wrote: > Paul Moore writes: > >  > End users should not need packaging tools on their machines. > > I think this desideratum is close to obsolete these days, with webapps > in "the cloud" downloading resources (including, but not limited to, > c

Re: [Python-Dev] Status of packaging in 3.3

On Fri, Jun 22, 2012 at 3:20 PM, Donald Stufft wrote: > I don't want to argue over implementation details as I think that is > premature right now, so this > concept has a big +1 from me. RPM, deb, etc has a long history and a lot of > shared knowledge > so looking at them and adapting it to work

Re: [Python-Dev] Status of packaging in 3.3

Paul Moore writes: > End users should not need packaging tools on their machines. I think this desideratum is close to obsolete these days, with webapps in "the cloud" downloading resources (including, but not limited to, code) on an as-needed basis. If you're *not* obtaining resources as-neede

Re: [Python-Dev] Status of packaging in 3.3

On Friday, June 22, 2012 at 1:05 AM, Nick Coghlan wrote: > > - I reject setup.cfg, as I believe ini-style configuration files are > not appropriate for a metadata format that needs to include file > listings and code fragments > > - I reject bento.info (http://bento.info), as I think if we accept

Re: [Python-Dev] PEP 362 - request for pronouncement

On Fri, Jun 22, 2012 at 11:56 AM, Yury Selivanov wrote: > Hello, > > On behalf of Brett, Larry, and myself, I'm requesting for PEP 362 > pronouncement. > > The PEP, has been updated with all feedback from python-dev list > discussions. I'm posting the latest version of it with this message. > The

Re: [Python-Dev] Status of packaging in 3.3

On Fri, Jun 22, 2012 at 10:01 AM, Donald Stufft wrote: > The idea i'm hoping for is to stop worrying about one implementation over > another and > hoping to create a common format that all the tools can agree upon and > create/install. Right, and this is where it encouraged me to see in the Bento

[Python-Dev] PEP 362 - request for pronouncement

Hello, On behalf of Brett, Larry, and myself, I'm requesting for PEP 362 pronouncement. The PEP, has been updated with all feedback from python-dev list discussions. I'm posting the latest version of it with this message. The PEP is also available here: http://www.python.org/dev/peps/pep-0362/

Re: [Python-Dev] Accepting PEP 397

On 22/06/2012 8:14 AM, Brian Curtin wrote: On Wed, Jun 20, 2012 at 11:54 AM, Brian Curtin wrote: As the PEP czar for 397, after Martin's final updates, I hereby pronounce this PEP "accepted"! Thanks to Mark Hammond for kicking it off, Vinay Sajip for writing up the code, Martin von Loewis for

Re: [Python-Dev] Status of packaging in 3.3

On Thursday, June 21, 2012 at 7:34 PM, Alex Clark wrote: > Hi, > > On 6/21/12 5:38 PM, Donald Stufft wrote: > > On Thursday, June 21, 2012 at 4:01 PM, Paul Moore wrote: > > > End users should not need packaging tools on their machines. > > > > Sort of riffing on this idea, I cannot seem to find a

Re: [Python-Dev] Status of packaging in 3.3

Hi, On 6/21/12 5:38 PM, Donald Stufft wrote: On Thursday, June 21, 2012 at 4:01 PM, Paul Moore wrote: End users should not need packaging tools on their machines. Sort of riffing on this idea, I cannot seem to find a specification for what a Python package actually is. FWIW according to di

Re: [Python-Dev] Status of packaging in 3.3

On 6/21/12 11:55 PM, David Cournapeau wrote: I think there is a misunderstanding of what bento is: bento is not a compiler or anything like that. It is a set of libraries that work together to configure, build and install a python project. Concretely, in bento, there is - a part that buil

Re: [Python-Dev] Status of packaging in 3.3

On Thu, Jun 21, 2012 at 11:00 PM, Antoine Pitrou wrote: > On Thu, 21 Jun 2012 22:46:58 +0200 > Dag Sverre Seljebotn wrote: > > > The other thing is, the folks in distutils2 and myself, have zero > > > knowledge about compilers. That's why we got very frustrated not to see > > > people with that k

Re: [Python-Dev] Status of packaging in 3.3

On 06/22/2012 12:05 AM, Dag Sverre Seljebotn wrote: On 06/21/2012 11:04 PM, Tarek Ziadé wrote: On 6/21/12 10:46 PM, Dag Sverre Seljebotn wrote: ... I think we should, as you proposed, list a few projects w/ compilation needs -- from the simplest to the more complex, then see how a standard *des

Re: [Python-Dev] Accepting PEP 397

On Wed, Jun 20, 2012 at 11:54 AM, Brian Curtin wrote: > As the PEP czar for 397, after Martin's final updates, I hereby > pronounce this PEP "accepted"! > > Thanks to Mark Hammond for kicking it off, Vinay Sajip for writing up > the code, Martin von Loewis for recent updates, and everyone in the >

Re: [Python-Dev] Status of packaging in 3.3

On 06/21/2012 11:04 PM, Tarek Ziadé wrote: On 6/21/12 10:46 PM, Dag Sverre Seljebotn wrote: ... I think we should, as you proposed, list a few projects w/ compilation needs -- from the simplest to the more complex, then see how a standard *description* could be used by any tool It's not clear

Re: [Python-Dev] Status of packaging in 3.3

On Thu, 21 Jun 2012 22:46:58 +0200 Dag Sverre Seljebotn wrote: > > The other thing is, the folks in distutils2 and myself, have zero > > knowledge about compilers. That's why we got very frustrated not to see > > people with that knowledge come and help us in this area. > > Here's the flip side:

Re: [Python-Dev] Status of packaging in 3.3

On Thu, Jun 21, 2012 at 10:04 PM, Tarek Ziadé wrote: > On 6/21/12 10:46 PM, Dag Sverre Seljebotn wrote: > ... > > I think we should, as you proposed, list a few projects w/ compilation >>> needs -- from the simplest to the more complex, then see how a standard >>> *description* could be used by

Re: [Python-Dev] Status of packaging in 3.3

On Thursday, June 21, 2012 at 4:01 PM, Paul Moore wrote: > End users should not need packaging tools on their machines. > Sort of riffing on this idea, I cannot seem to find a specification for what a Python package actually is. Maybe the first effort should focus on this instead of arguing one

Re: [Python-Dev] Status of packaging in 3.3

On 6/21/12 10:46 PM, Dag Sverre Seljebotn wrote: ... I think we should, as you proposed, list a few projects w/ compilation needs -- from the simplest to the more complex, then see how a standard *description* could be used by any tool It's not clear to me what you mean by description. Package

Re: [Python-Dev] Status of packaging in 3.3

On 06/21/2012 09:05 PM, Tarek Ziadé wrote: On 6/21/12 4:26 PM, Dag Sverre Seljebotn wrote: project should give me so I can compile its extensions ?" I think this has nothing to do with the tools/implementations. If you sit down and ask your self: "what are the information a python I'm not su

Re: [Python-Dev] Status of packaging in 3.3

On Thu, Jun 21, 2012 at 4:01 PM, Paul Moore wrote: > End users should not need packaging tools on their machines. > Well, unless they're developers. ;-) Sometimes, the "end user" is a developer making use of a library. Development tools like distutils2, distribute/setuptools, bento would > *

Re: [Python-Dev] Status of packaging in 3.3

Can I take a step back and make a somewhat different point. Developer requirements are very relevant, sure. But the most important requirements are those of the end user. The person who simply wants to *use* a distribution, couldn't care less how it was built, whether it uses setuptools, or whatev

Re: [Python-Dev] Status of packaging in 3.3

On 6/21/12 7:56 PM, Chris McDonough wrote: ... think any API has been removed or modified. In my opinion, distribute is the only project that should go forward since it's actively maintained and does not suffer from the bus factor. Yeah the biggest difference is Py3 compat, other than that af

Re: [Python-Dev] Status of packaging in 3.3

On 6/21/12 4:26 PM, Dag Sverre Seljebotn wrote: project should give me so I can compile its extensions ?" I think this has nothing to do with the tools/implementations. If you sit down and ask your self: "what are the information a python I'm not sure if I understand. A project can't "give th

Re: [Python-Dev] Status of packaging in 3.3

On 6/21/12 7:49 PM, PJ Eby wrote: On Thu, Jun 21, 2012 at 1:20 PM, Tarek Ziadé > wrote: telling us no one that is willing to maintain setuptools is able to do so. (according to him) Perhaps there is some confusion or language barrier here: what I said at that t

Re: [Python-Dev] import too slow on NFS based systems

On Thu, Jun 21, 2012 at 10:08 AM, Daniel Braniss wrote: > > On Thu, 21 Jun 2012 13:17:01 +0300 > > Daniel Braniss wrote: > > > Hi, > > > when lib/python/site-packages/ is accessed via NFS, open/stat/access > is very > > > expensive/slow. > > > > > > A simple solution is to use an in memory direct

Re: [Python-Dev] Status of packaging in 3.3

On 06/21/2012 01:20 PM, Tarek Ziadé wrote: On 6/21/12 6:44 PM, Chris McDonough wrote: Yes. At the very least, there will be updated development snapshots (which are what buildout uses anyway). (Official releases are in a bit of a weird holding pattern. distribute's versioning scheme leads to

Re: [Python-Dev] Status of packaging in 3.3

On Thu, Jun 21, 2012 at 1:20 PM, Tarek Ziadé wrote: > telling us no one that is willing to maintain setuptools is able to do so. > (according to him) Perhaps there is some confusion or language barrier here: what I said at that time was that the only people who I already *knew* to be capable of

Re: [Python-Dev] Status of packaging in 3.3

Hi, On 6/21/12 1:20 PM, Tarek Ziadé wrote: On 6/21/12 6:44 PM, Chris McDonough wrote: Yes. At the very least, there will be updated development snapshots (which are what buildout uses anyway). (Official releases are in a bit of a weird holding pattern. distribute's versioning scheme leads t

Re: [Python-Dev] [Python-checkins] peps: The latest changes from Yury Selivanov. I can almost taste the acceptance!

On 2012-06-21, at 11:34 AM, Eric Snow wrote: > On Thu, Jun 21, 2012 at 2:44 AM, larry.hastings > wrote: >> http://hg.python.org/peps/rev/1edf1cecae7d >> changeset: 4472:1edf1cecae7d >> user:Larry Hastings >> date:Thu Jun 21 01:44:15 2012 -0700 >> summary: >> The latest changes

[Python-Dev] PEP 362 6th edition

Hello, The new revision of PEP 362 has been posted: http://www.python.org/dev/peps/pep-0362/ Summary: 1. Signature & Parameter objects are now immutable 2. Signature.replace() and Parameter.replace() 3. Signature has a new default constructor, which accepts parameters list and a return_annotat

Re: [Python-Dev] Status of packaging in 3.3

On 6/21/12 6:44 PM, Chris McDonough wrote: Yes. At the very least, there will be updated development snapshots (which are what buildout uses anyway). (Official releases are in a bit of a weird holding pattern. distribute's versioning scheme leads to potential confusion: if I release e.g. 0.6.

Re: [Python-Dev] Status of packaging in 3.3

On 06/21/2012 12:26 PM, PJ Eby wrote: On Thu, Jun 21, 2012 at 11:50 AM, Chris McDonough mailto:chr...@plope.com>> wrote: On 06/21/2012 11:37 AM, PJ Eby wrote: On Jun 21, 2012 11:02 AM, "Zooko Wilcox-O'Hearn" mailto:zo...@zooko.com>

Re: [Python-Dev] Status of packaging in 3.3

On Thu, Jun 21, 2012 at 11:50 AM, Chris McDonough wrote: > On 06/21/2012 11:37 AM, PJ Eby wrote: > >> >> On Jun 21, 2012 11:02 AM, "Zooko Wilcox-O'Hearn" > > wrote: >> > >> > Philip J. Eby provisionally approved of one of the patches, except for >> > some specific requi

Re: [Python-Dev] Status of packaging in 3.3

On 6/21/12 5:50 PM, Chris McDonough wrote: A minor backwards incompat here to fix that issue would be appropriate, if only to be able to say "hey, that issue no longer exists" to folks who condemn the entire ecosystem based on that bug. At least, that is, if there will be another release of se

Re: [Python-Dev] Status of packaging in 3.3

On 06/21/2012 11:45 AM, PJ Eby wrote: On Jun 21, 2012 10:12 AM, "Chris McDonough" mailto:chr...@plope.com>> wrote: > - Install "package resources", which are non-Python source files that > happen to live in package directories. I love this phrasing, by the way ("non-Python source files"). A

Re: [Python-Dev] Status of packaging in 3.3

On 06/21/2012 11:37 AM, PJ Eby wrote: On Jun 21, 2012 11:02 AM, "Zooko Wilcox-O'Hearn" mailto:zo...@zooko.com>> wrote: > > Philip J. Eby provisionally approved of one of the patches, except for > some specific requirement that I didn't really understand how to fix > and that now I don't exac

Re: [Python-Dev] Status of packaging in 3.3

On Fri, Jun 22, 2012 at 12:59 AM, Chris McDonough wrote: > On 06/21/2012 10:30 AM, Nick Coghlan wrote: >> That will give at least 3 mechanisms for Python code to get onto a system: >> >> 1. Python dist ->  converter ->  system package ->  system Python path >> >> 2. Python dist ->  system Python i

Re: [Python-Dev] Status of packaging in 3.3

On Jun 21, 2012 10:12 AM, "Chris McDonough" wrote: > - Install "package resources", which are non-Python source files that > happen to live in package directories. I love this phrasing, by the way ("non-Python source files"). A pet peeve of mine is the insistence by some people that such files

Re: [Python-Dev] Status of packaging in 3.3

On Jun 21, 2012 11:02 AM, "Zooko Wilcox-O'Hearn" wrote: > > Philip J. Eby provisionally approved of one of the patches, except for > some specific requirement that I didn't really understand how to fix > and that now I don't exactly remember: > > http://mail.python.org/pipermail/distutils-sig/2009

Re: [Python-Dev] [Python-checkins] peps: The latest changes from Yury Selivanov. I can almost taste the acceptance!

On Thu, Jun 21, 2012 at 2:44 AM, larry.hastings wrote: > http://hg.python.org/peps/rev/1edf1cecae7d > changeset:   4472:1edf1cecae7d > user:        Larry Hastings > date:        Thu Jun 21 01:44:15 2012 -0700 > summary: >  The latest changes from Yury Selivanov.  I can almost taste the acceptance

Re: [Python-Dev] Status of packaging in 3.3

Nick Coghlan gmail.com> writes: > > The Python community covers a broad spectrum of use cases, and I > suspect that's one of the big reasons packaging can get so contentious > - the goals end up being in direct conflict. Currently, I've > identified at least half a dozen significant communities

Re: [Python-Dev] Status of packaging in 3.3

On Thu, 21 Jun 2012 12:02:58 -0300 "Zooko Wilcox-O'Hearn" wrote: > > Fortunately, this issue is fixable! I opened a bug report and I and a > others have provided patches that makes setuptools stop doing this > behavior. This makes the above documentation true again. The negative > impact on featu

Re: [Python-Dev] Status of packaging in 3.3

On Thu, Jun 21, 2012 at 12:57 AM, Nick Coghlan wrote: > > Standard assumptions about the behaviour of site and distutils cease to be > valid once setuptools is installed … > - advocacy for the "egg" format and the associated sys.path changes that > result for all Python programs running on a sys

Re: [Python-Dev] Status of packaging in 3.3

On 06/21/2012 10:30 AM, Nick Coghlan wrote: A tool to generate an OS-specific system package from a Python library project should be unrelated to a Python distribution *installer*. Instead, you'd use related tools that understood how to unpack the distribution packaging format to build one or mor

Re: [Python-Dev] Add os.path.resolve to simplify the use of os.readlink

On Thu, 21 Jun 2012 10:23:25 - "Armin Ronacher" wrote: > Due to an user error on my part I was not using os.readlink correctly. > Since links can be relative to their location I think it would make sense > to provide an os.path.resolve helper that automatically returns the > absolute path: >

Re: [Python-Dev] Add os.path.resolve to simplify the use of os.readlink

On 2012-06-21 06:23, Armin Ronacher wrote: Due to an user error on my part I was not using os.readlink correctly. Since links can be relative to their location I think it would make sense to provide an os.path.resolve helper that automatically returns the absolute path: def resolve(filename

Re: [Python-Dev] Status of packaging in 3.3

On Fri, Jun 22, 2012 at 12:12 AM, Chris McDonough wrote: > On 06/21/2012 09:29 AM, Nick Coghlan wrote: >>> >>> My only comment on that is this: Since this is a problem related to the >>> installation of Python distributions, it should deal with the problems >>> that >>> Python developers have more

Re: [Python-Dev] Status of packaging in 3.3

On 06/21/2012 03:23 PM, Tarek Ziadé wrote: On 6/21/12 2:45 PM, Dag Sverre Seljebotn wrote: Guido was asked about build issues and scientific software at PyData this spring, and his take was that "if scientific users have concerns that are that special, perhaps you just need to go and do your ow

Re: [Python-Dev] import too slow on NFS based systems

On Thu, 21 Jun 2012 17:08:09 +0300 Daniel Braniss wrote: > > There is such a thing in Python 3.3, although some stat() calls are > > still necessary to know whether the directory caches are fresh. > > Can you give it a try and provide some feedback? > > WOW! > with a sample python program: > > i

Re: [Python-Dev] Add os.path.resolve to simplify the use of os.readlink

On Thu, Jun 21, 2012 at 11:16 PM, Antoine Pitrou wrote: > On Thu, 21 Jun 2012 15:04:17 +0200 > Christian Heimes wrote: >> >> How about adding keyword support to OSError and derive the strerror from >> errno if the second argument is not given? > > That's not the original behaviour: > > Python 3.2

Re: [Python-Dev] Status of packaging in 3.3

On Thu, Jun 21, 2012 at 11:57 PM, Barry Warsaw wrote: > On Jun 21, 2012, at 07:48 AM, Chris McDonough wrote: > >>I don't know about Red Hat but both Ubuntu and Apple put all kinds of stuff >>on the default sys.path of the system Python of the box that's related to >>their software's concerns only.

Re: [Python-Dev] Status of packaging in 3.3

On 06/21/2012 09:29 AM, Nick Coghlan wrote: My only comment on that is this: Since this is a problem related to the installation of Python distributions, it should deal with the problems that Python developers have more forcefully than non-Python developers and non-programmers. Thanks to venv,

Re: [Python-Dev] Status of packaging in 3.3

On Jun 21, 2012, at 08:51 AM, Chris McDonough wrote: >The reason it's disappointing to see OS vendors mutating the default sys.path >is because they put *very old versions of very common non-stdlib packages* >(e.g. zope.interface, lxml) on sys.path by default. The path is tainted out >of the box

Re: [Python-Dev] Status of packaging in 3.3

Hi, On 6/21/12 7:56 AM, Tarek Ziadé wrote: On 6/21/12 11:08 AM, Dag Sverre Seljebotn wrote: ... David Cournapeau's Bento project takes the opposite approach, everything is explicit and without any magic. http://cournape.github.com/Bento/ It had its 0.1.0 release a week ago. Please, I don't w

Re: [Python-Dev] import too slow on NFS based systems

> On Thu, 21 Jun 2012 13:17:01 +0300 > Daniel Braniss wrote: > > Hi, > > when lib/python/site-packages/ is accessed via NFS, open/stat/access is very > > expensive/slow. > > > > A simple solution is to use an in memory directory search/hash, so I was > > wondering if this has been concidered in

Re: [Python-Dev] Status of packaging in 3.3

On Thu, Jun 21, 2012 at 11:31 PM, PJ Eby wrote: > So, if we are to draw any lesson from the past, it would seem to be, "make > sure that the people who'll be doing the work are actually going to be > available through to the next Python version". Thanks for that write-up - I learned quite a few t

Re: [Python-Dev] Status of packaging in 3.3

On Jun 21, 2012, at 07:48 AM, Chris McDonough wrote: >I don't know about Red Hat but both Ubuntu and Apple put all kinds of stuff >on the default sys.path of the system Python of the box that's related to >their software's concerns only. I don't understand why people accept this >but get crazy ab

Re: [Python-Dev] Status of packaging in 3.3

Chris McDonough plope.com> writes: > On 06/21/2012 04:45 AM, Nick Coghlan wrote: > > A packaging PEP needs to explain: > > - what needs to be done to eliminate any need for monkeypatching > > - what's involved in making sure that *.pth are *not* needed by default > > - making sure that executable

Re: [Python-Dev] Status of packaging in 3.3

On Wed, Jun 20, 2012 at 11:57 PM, Nick Coghlan wrote: > > Right - clearly enumerating the features that draw people to use > setuptools over just using distutils should be a key element in any > PEP for 3.4 > > I honestly think a big part of why packaging ended up being incomplete > for 3.3 is tha

Re: [Python-Dev] Status of packaging in 3.3

On Thu, Jun 21, 2012 at 10:51 PM, Chris McDonough wrote: > Is it reasonable to even assume there is only one-sys.path-to-rule-them-all? > And that users install "the set of libraries they need" into a common place? >  This quickly turns into failure, because Python is used for many, many > tasks,

Re: [Python-Dev] Status of packaging in 3.3

On 6/21/12 2:45 PM, Dag Sverre Seljebotn wrote: Guido was asked about build issues and scientific software at PyData this spring, and his take was that "if scientific users have concerns that are that special, perhaps you just need to go and do your own thing". Which is what David is doing.

Re: [Python-Dev] Add os.path.resolve to simplify the use of os.readlink

On Thu, 21 Jun 2012 15:04:17 +0200 Christian Heimes wrote: > > How about adding keyword support to OSError and derive the strerror from > errno if the second argument is not given? That's not the original behaviour: Python 3.2.2+ (3.2:9ef20fbd340f, Oct 15 2011, 21:22:07) [GCC 4.5.2] on linux2

Re: [Python-Dev] Add os.path.resolve to simplify the use of os.readlink

Am 21.06.2012 14:55, schrieb Nick Coghlan: > On Thu, Jun 21, 2012 at 9:26 PM, Christian Heimes wrote: >> BTW Is there a better way than raise OSError(errno.ELOOP, >> os.strerror(errno.ELOOP), filename) to raise a correct OSError with >> errno, errno message and filename? A classmethod like >> "OSE

Re: [Python-Dev] Add os.path.resolve to simplify the use of os.readlink

On Thu, Jun 21, 2012 at 9:26 PM, Christian Heimes wrote: > BTW Is there a better way than raise OSError(errno.ELOOP, > os.strerror(errno.ELOOP), filename) to raise a correct OSError with > errno, errno message and filename? A classmethod like > "OSError.from_errno(errno, filename=None) -> proper s

Re: [Python-Dev] Status of packaging in 3.3

On 06/21/2012 08:21 AM, Nick Coghlan wrote: Installing a distribution will change behavior whether or not sys.path is changed as a result. That's its purpose. No it won't. An ordinary package will only change the behaviour of Python applications that import a package by that name. Other Pyth

Re: [Python-Dev] Status of packaging in 3.3

On 06/21/2012 01:56 PM, Tarek Ziadé wrote: On 6/21/12 11:08 AM, Dag Sverre Seljebotn wrote: ... David Cournapeau's Bento project takes the opposite approach, everything is explicit and without any magic. http://cournape.github.com/Bento/ It had its 0.1.0 release a week ago. Please, I don't wa

Re: [Python-Dev] Status of packaging in 3.3

On Thu, Jun 21, 2012 at 10:19 PM, David Cournapeau wrote: > > > On Thu, Jun 21, 2012 at 12:58 PM, Nick Coghlan wrote: >> >> On Thu, Jun 21, 2012 at 7:28 PM, David Cournapeau >> wrote: >> > If specifying install dependencies is the killer feature of setuptools, >> > why >> > can't we have a very

Re: [Python-Dev] Status of packaging in 3.3

On Thu, Jun 21, 2012 at 9:48 PM, Chris McDonough wrote: > On 06/21/2012 04:45 AM, Nick Coghlan wrote: >> And, like it or not, setuptools has a serious PR problem due to the >> fact it monkeypatches the standard library, uses *.pth files to alter >> sys.path for every installed application by defau

Re: [Python-Dev] Status of packaging in 3.3

On Thu, Jun 21, 2012 at 12:58 PM, Nick Coghlan wrote: > On Thu, Jun 21, 2012 at 7:28 PM, David Cournapeau > wrote: > > If specifying install dependencies is the killer feature of setuptools, > why > > can't we have a very simple module that adds the necessary 3 keywords to > > record it, and let

Re: [Python-Dev] Status of packaging in 3.3

On 21 June 2012 12:48, Chris McDonough wrote: > On 06/21/2012 04:45 AM, Nick Coghlan wrote: > >> On Thu, Jun 21, 2012 at 2:44 PM, Chris McDonough >> wrote: >> >>> All of these are really pretty minor issues compared with the main >>> benefit >>> of not needing to ship everything with everything

Re: [Python-Dev] Status of packaging in 3.3

On 6/20/12 2:53 PM, Nick Coghlan wrote: On Wed, Jun 20, 2012 at 9:31 PM, Tarek Ziadé wrote: Yeah maybe this subset could be left in 3.3 and we'd remove packaging-the-installer part (pysetup, commands, compilers) I think it's a good idea ! OK, to turn this into a concrete suggestion based on

Re: [Python-Dev] Status of packaging in 3.3

On Thu, Jun 21, 2012 at 7:28 PM, David Cournapeau wrote: > If specifying install dependencies is the killer feature of setuptools, why > can't we have a very simple module that adds the necessary 3 keywords to > record it, and let 3rd party tools deal with it as they wish ? That would > not even r

Re: [Python-Dev] Status of packaging in 3.3

On 6/21/12 11:08 AM, Dag Sverre Seljebotn wrote: ... David Cournapeau's Bento project takes the opposite approach, everything is explicit and without any magic. http://cournape.github.com/Bento/ It had its 0.1.0 release a week ago. Please, I don't want to reopen any discussions about Bento h

Re: [Python-Dev] Status of packaging in 3.3

On 06/21/2012 04:45 AM, Nick Coghlan wrote: On Thu, Jun 21, 2012 at 2:44 PM, Chris McDonough wrote: All of these are really pretty minor issues compared with the main benefit of not needing to ship everything with everything else. The killer feature is that developers can specify dependencies a

[Python-Dev] Fwd: Re: Add os.path.resolve to simplify the use of os.readlink

-- Forwarded message -- (whoops from my phone) On Jun 21, 2012 6:32 AM, "Armin Ronacher" wrote: > > Due to an user error on my part I was not using os.readlink correctly. > Since links can be relative to their location I think it would make sense > to provide an os.path.resolve he

Re: [Python-Dev] Add os.path.resolve to simplify the use of os.readlink

On Thu, Jun 21, 2012 at 11:10:44AM -, Armin Ronacher wrote: > would have to check the POSIX spec for a > reasonable value POSIX allows 8 links: http://infohost.nmt.edu/~eweiss/222_book/222_book/0201433079/ch02lev1sec5.html _POSIX_SYMLOOP_MAX - number of symbolic links that can be traver

Re: [Python-Dev] Add os.path.resolve to simplify the use of os.readlink

Am 21.06.2012 13:10, schrieb Armin Ronacher: Hello Armin, > No, but that's a good point. It should attempt to resolve these in a loop > until it either loops too often (would have to check the POSIX spec for a > reasonable value) or until it terminates by finding an actual file or > directory. T

Re: [Python-Dev] Add os.path.resolve to simplify the use of os.readlink

On Thu, 21 Jun 2012 11:10:44 - "Armin Ronacher" wrote: > Hi, > > > Am 21.06.2012 12:23, schrieb Armin Ronacher: > > Does the code handle a chain of absolute and relative symlinks > > correctly, for example a relative symlink that points to another > > relative symlink in a different directory

Re: [Python-Dev] Add os.path.resolve to simplify the use of os.readlink

Hi, > Am 21.06.2012 12:23, schrieb Armin Ronacher: > Does the code handle a chain of absolute and relative symlinks > correctly, for example a relative symlink that points to another > relative symlink in a different directory that points to a file in a > third directry? No, but that's a good poin

Re: [Python-Dev] Add os.path.resolve to simplify the use of os.readlink

Am 21.06.2012 12:23, schrieb Armin Ronacher: > Due to an user error on my part I was not using os.readlink correctly. > Since links can be relative to their location I think it would make sense > to provide an os.path.resolve helper that automatically returns the > absolute path: > > def reso

Re: [Python-Dev] import too slow on NFS based systems

On Thu, 21 Jun 2012 13:17:01 +0300 Daniel Braniss wrote: > Hi, > when lib/python/site-packages/ is accessed via NFS, open/stat/access is very > expensive/slow. > > A simple solution is to use an in memory directory search/hash, so I was > wondering if this has been concidered in the past, if not

[Python-Dev] Add os.path.resolve to simplify the use of os.readlink

Due to an user error on my part I was not using os.readlink correctly. Since links can be relative to their location I think it would make sense to provide an os.path.resolve helper that automatically returns the absolute path: def resolve(filename): try: target = os.readl

Re: [Python-Dev] import too slow on NFS based systems

On Thu, Jun 21, 2012 at 01:17:01PM +0300, Daniel Braniss wrote: > when lib/python/site-packages/ is accessed via NFS, open/stat/access is very > expensive/slow. > > A simple solution is to use an in memory directory search/hash, so I was > wondering if this has been concidered in the past, if n

[Python-Dev] import too slow on NFS based systems

Hi, when lib/python/site-packages/ is accessed via NFS, open/stat/access is very expensive/slow. A simple solution is to use an in memory directory search/hash, so I was wondering if this has been concidered in the past, if not, and I come with a working solution for Unix (at least Linux/Freebsd)

Re: [Python-Dev] Status of packaging in 3.3

On Thu, Jun 21, 2012 at 9:45 AM, Nick Coghlan wrote: > On Thu, Jun 21, 2012 at 2:44 PM, Chris McDonough wrote: > > All of these are really pretty minor issues compared with the main > benefit > > of not needing to ship everything with everything else. The killer > feature > > is that developers

Re: [Python-Dev] Status of packaging in 3.3

On 06/21/2012 05:57 AM, Nick Coghlan wrote: On Thu, Jun 21, 2012 at 3:29 AM, PJ Eby wrote: On Wed, Jun 20, 2012 at 9:02 AM, Nick Coghlan wrote: On Wed, Jun 20, 2012 at 9:46 PM, Antoine Pitrou wrote: Agreed, especially if the "proven in the wild" criterion is required (people won't rush to a

Re: [Python-Dev] Cannot find the main Python library during installing some app.

Hello. We are sorry but we cannot help you. This mailing list is to work on developing Python (adding new features to Python itself and fixing bugs); if you're having problems learning, understanding or using Python, please find another forum. Probably python-list/comp.lang.python mailing list/

Re: [Python-Dev] Cannot find the main Python library during installing some app.

Hi, This mailing list is for the development *of* Python. Development *with* Python should be discussed on the python-list mailing list, or the comp.lang.python usenet group. There will be many people there willing to answer your question... 2012/6/21 Van Gao > hi, > > I got the error below dur

[Python-Dev] Cannot find the main Python library during installing some app.

hi, I got the error below during installing the libmobiledevice: checking consistency of all components of *python development environment... no* configure: error: Could not link test program to Python. Maybe the main Python library has been installed in some non-standard library path. If so,

Re: [Python-Dev] Status of packaging in 3.3

On Thu, Jun 21, 2012 at 2:44 PM, Chris McDonough wrote: > All of these are really pretty minor issues compared with the main benefit > of not needing to ship everything with everything else. The killer feature > is that developers can specify dependencies and users can have those > dependencies in