On Sat, Dec 12, 2009 at 9:02 PM, Tarek Ziadé wrote:
> Hello,
>
> A while ago I've proposed to refactor the APIs that provides access to
> the installation paths and configuration variables at runtime into a
> single module called "sysconfig", and make it easier for all
> implementations to work wi
2009/12/23 Glyph Lefkowitz :
[..]
> 2. I think it would be a better idea to do
> "~/.local/lib/jython/2.6/site-packages".
>
> The idea with ~/.local is that it's a mirror of the directory structure
> convention in /, /usr/, /opt/ or /usr/local/. In other words it's got "bin",
> "lib", "share",
On Dec 23, 2009, at 10:00 AM, Frank Wierzbicki wrote:
> On Mon, Dec 14, 2009 at 5:58 PM, Tarek Ziadé wrote:
>> and for Linux and al, I am not sure but maybe a prefix for
>> Jython/etc.. could be used
>> for all paths.
>>
>> ~/.locale/lib/python/2.6/site-packages/...
>> ~/.locale/jython/lib/pyth
On Mon, Dec 14, 2009 at 5:58 PM, Tarek Ziadé wrote:
> and for Linux and al, I am not sure but maybe a prefix for
> Jython/etc.. could be used
> for all paths.
>
> ~/.locale/lib/python/2.6/site-packages/...
> ~/.locale/jython/lib/python/2.6/site-packages/...
>
> (I didn't digg on how Jython organiz
On Tue, Dec 15, 2009 at 6:59 PM, Dino Viehland wrote:
> Tarek wrote:
>> How would you use it when a list is returned ? Can you provide a few
>> examples where
>> the code wants to know the default architecture for the current platform ?
>> etc.
>
> The consumer could enumerate over it and then do
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
David Lyon writes:
> I'm not star-gazing, 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.
Sure. But in a volunteer project, it's beg, buy, or build. Begging
has not
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
David Lyon wrote:
> I was thinking that perphaps sysconfig could help me get my
> helloworld.py application into a \Program Files\hello world
> directory and everything would be rosy.
>
> But not yet. So I will wait.
No, we mostly leave that to the py2exe/py2app + native installer
developers of t
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
Tarek Ziadé wrote:
> On Mon, Dec 14, 2009 at 10:52 AM, M.-A. Lemburg wrote:
> [..]
>>> I've refactored distutils/ and site.py so they work with this new
>>> module, and added deprecation warnings in distutils.sysconfig.
>>
>> I think we really need to do something about these kinds of
>> deprecati
Tarek wrote:
> How would you use it when a list is returned ? Can you provide a few
> examples where
> the code wants to know the default architecture for the current platform ?
> etc.
The consumer could enumerate over it and then do whatever they were doing
w/ the platform multiple times. If an
On Tue, Dec 15, 2009 at 5:12 AM, Ben Finney wrote:
[..]
>
>> > I don't think they belong in this PEP; they are a property of the OS
>> > install/version, not of the specific Python install/version.
>
> I think the “sysconfig” specification should allow for *extension*,
> without needing a modified
On Tue, Dec 15, 2009 at 1:00 AM, Dino Viehland wrote:
[..]
> How would you know what other architectures would be valid to pass in
> here? Returning a list would let the implementation say that it knows
> a certain set of architectural binaries are valid.
How would you use it when a list is retu
On Mon, Dec 14, 2009 at 11:39:02PM -0500, David Lyon wrote:
> 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
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 15/12/2009 3:09 PM, David Lyon wrote:
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 agre
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
David Lyon writes:
> 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 deve
On 15/12/2009 2:42 PM, David Lyon wrote:
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
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
On 15/12/2009 2:07 PM, David Lyon wrote:
Hi Tarek,
Is there anything in this proposal for windows developers ?
Just that I can't see anything that would help us...
So I understand - help doing what?
For me, the terminology isn't anything a windows developer could
really understand. It pres
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
Antoine wrote:
> Dino Viehland microsoft.com> writes:
> >
> > > * get_platform(): Return a string that identifies the current
> > > platform. (this one is used by site.py for example)
> >
> > I wonder if this would make more sense a built-in. Ultimately it seems
> > like the interpreter implemen
Tarek wrote:
>
> (I didn't digg on how Jython organizes things yet, any hint would be
> appreciated)
The installation directory looks like it's organized just like CPython
but I have no clue how user directories would/should be arranged.
>
> >
> > Also if the purpose of this is for platform spe
Dino Viehland microsoft.com> writes:
>
> > * get_platform(): Return a string that identifies the current
> > platform. (this one is used by site.py for example)
>
> I wonder if this would make more sense a built-in. Ultimately it seems
> like the interpreter implementation knows best about wh
2009/12/14 Dino Viehland :
[..]
> Not mentioned here are the user schemes. Looking at the code it seems that
> _getuserbase is adding "Python" to the path on nt. Isn't that redundant?
> The paths in _INSTALL_SCHEMES already include "Python".
>
Right that's a small bug in the refactoring (there's
On Mon, Dec 14, 2009 at 10:52 AM, M.-A. Lemburg wrote:
[..]
>> I've refactored distutils/ and site.py so they work with this new
>> module, and added deprecation warnings in distutils.sysconfig.
>
> I think we really need to do something about these kinds of
> deprecations.
>
> IMHO, there is no n
Tarek wrote:
> == Installation schemes ==
>
> First, the module contains the installation schemes for each platform
> CPython uses.
> An install scheme is a mapping where the key is the "code" name for a
> directory, and
> the value the path of that directory, with some $variable that can be
> exp
Tarek Ziadé wrote:
> == code, status, next steps ==
>
> The code of the module can be viewed here, it's a revamp of
> distutils.sysconfig:
>
> http://svn.python.org/view/*checkout*/python/branches/tarek_sysconfig/Lib/sysconfig.py?content-type=text%2Fplain
>
> I've refactored distutils/ and site
That's what I meant.
[From my phone]
On Dec 12, 2009 4:32 PM, "Eric Smith" wrote:
Tarek Ziadé wrote: > > On Sat, Dec 12, 2009 at 10:35 PM, Brett Cannon <
br...@python.org> wrote: > [
I don't really understand the complete context, but I think you want
str.format(), not string.Formatter here
Tarek Ziadé wrote:
On Sat, Dec 12, 2009 at 10:35 PM, Brett Cannon wrote:
[...]
'nt': {
'stdlib': '$base/Lib',
'platstdlib': '$base/Lib',
'purelib': '$base/Lib/site-packages',
'platlib': '$base/Lib/site-packages',
'include': '$base/include',
'platinclud
On Sat, Dec 12, 2009 at 11:18 PM, Brett Cannon wrote:
[..]
>> Not really. That's mostly because I reused the existing implementation
>> and I found them quite readable in that case. But a string.Formatter
>> could work well here too I guess.
>
> Just figured that with formatters the way of the fut
On Sat, Dec 12, 2009 at 14:13, Tarek Ziadé wrote:
> On Sat, Dec 12, 2009 at 10:35 PM, Brett Cannon wrote:
> [...]
> >> 'nt': {
> >>'stdlib': '$base/Lib',
> >>'platstdlib': '$base/Lib',
> >>'purelib': '$base/Lib/site-packages',
> >>'platlib': '$base/Lib/site-packa
On Sat, Dec 12, 2009 at 10:35 PM, Brett Cannon wrote:
[...]
>> 'nt': {
>> 'stdlib': '$base/Lib',
>> 'platstdlib': '$base/Lib',
>> 'purelib': '$base/Lib/site-packages',
>> 'platlib': '$base/Lib/site-packages',
>> 'include': '$base/include',
>> 'platinclude
On Sat, Dec 12, 2009 at 12:02, Tarek Ziadé wrote:
> Hello,
>
> A while ago I've proposed to refactor the APIs that provides access to
> the installation paths and configuration variables at runtime into a
> single module called "sysconfig", and make it easier for all
> implementations to work wit
37 matches
Mail list logo