On Wed, Jul 8, 2009 at 7:09 AM, P.J. Eby wrote:
> At 11:30 PM 7/7/2009 +0200, Tarek Ziadé wrote:
>>
>> On Tue, Jul 7, 2009 at 10:31 PM, P.J. Eby wrote:
>> > At 03:23 PM 7/7/2009 +0200, Tarek Ziadé wrote:
>> >>
>> >> When I started to work on this I didn't realize the gigantic amount of
>> >> work a
> The reason I was a big vague is that I'm not really bothered HOW its
> done, I'd just like there to be some way to use PySys_SetArgv with a
> (char **)
Ok, that's easy:
void PySys_SetArgvChar(int argc, char** argv)
{
PySys_SetArgv(0, NULL);
}
So you don't bother *how* it's done as long as yo
At 11:30 PM 7/7/2009 +0200, Tarek Ziadé wrote:
On Tue, Jul 7, 2009 at 10:31 PM, P.J. Eby wrote:
> At 03:23 PM 7/7/2009 +0200, Tarek Ziadé wrote:
>>
>> When I started to work on this I didn't realize the gigantic amount of
>> work and coordination it requires
>
> No one expects the package inquisi
The reason I was a big vague is that I'm not really bothered HOW its
done, I'd just like there to be some way to use PySys_SetArgv with a
(char **)
Definitely not suggesting that PySys_SetArgv be reverted to the way it
worked in py2.x, if there was 2 versions of PySys_SetArgv that would
be accepta
R. David Murray writes:
> On Tue, 7 Jul 2009 at 15:26, M.-A. Lemburg wrote:
> > I've seen a few discussions about this, but no final statement
> > of what strategy to follow and whether hg makes this easier (AFAIR,
> > that was the main argument for switching to hg).
Yes, yes, yes, and no. I
Tarek Ziadé writes:
> On Tue, Jul 7, 2009 at 10:31 PM, P.J. Eby wrote:
> > No one expects the package inquisition. ;-)
> Sorry, i've looked in the english dictionary but I don't get this one.
I think that far more important than PEP 385 conversion of Roundup and
other utilities to recognize
Sorry...
-- Forwarded message --
From: Lisandro Dalcin
Date: Tue, Jul 7, 2009 at 7:16 PM
Subject: Re: [Python-Dev] Suggested PySys_SetArgv use with a (char **) argv ?
To: "Martin v. Löwis"
On Tue, Jul 7, 2009 at 6:46 PM, "Martin v. Löwis" wrote:
>> Since many C applications tak
> Since many C applications take argv as a (char **) it seems reasonable
> for python to keep a function for the C api that accepts a (char **)
> argument for argv.
I'm not quite sure what you are suggesting: either that there is a
function in the C API that accepts a (char**), or that PySys_SetA
Martin v. Löwis wrote:
> I think you are proposing that there is no prefix because the chance
> for a misidentification of some word as a hg revision number is small,
> as it has to be exactly 12 hex digits.
So triggering it accidentally would require a 12 letter word or object
name that used only
>> I've seen a few discussions about this, but no final statement
>> of what strategy to follow and whether hg makes this easier (AFAIR,
>> that was the main argument for switching to hg).
>
> I think the main reason for switching was that it would make it easier
> for non-core-committers to maint
Tarek Ziadé wrote:
> On Tue, Jul 7, 2009 at 10:31 PM, P.J. Eby wrote:
>> At 03:23 PM 7/7/2009 +0200, Tarek Ziadé wrote:
>>> When I started to work on this I didn't realize the gigantic amount of
>>> work and coordination it requires
>> No one expects the package inquisition. ;-)
>>
>>
>
> Sorry,
On Tue, 7 Jul 2009 at 23:30, Tarek Ziad? wrote:
On Tue, Jul 7, 2009 at 10:31 PM, P.J. Eby wrote:
At 03:23 PM 7/7/2009 +0200, Tarek Ziad? wrote:
When I started to work on this I didn't realize the gigantic amount of
work and coordination it requires
No one expects the package inquisition. ?;-
>> Hmm, no prefix or suffix ?
>
> No, not really. hg often shows revision integers as well, but as they
> aren't globally consistent, they're of little value in communicating
> changeset pointers.
I think MAL wasn't asking for a "1354:" prefix, but for a, say,
"r" or "R" prefix, or perhaps "V" or
On Tue, Jul 7, 2009 at 10:31 PM, P.J. Eby wrote:
> At 03:23 PM 7/7/2009 +0200, Tarek Ziadé wrote:
>>
>> When I started to work on this I didn't realize the gigantic amount of
>> work and coordination it requires
>
> No one expects the package inquisition. ;-)
>
>
Sorry, i've looked in the english
M.-A. Lemburg wrote:
> Dirkjan Ochtman wrote:
>> On Tue, Jul 7, 2009 at 10:16, M.-A. Lemburg wrote:
>>> Is there a standard notation for hg revisions that roundup could
>>> detect and turn into links (much like it does for svn) ?
>> [a-f0-9]{12} should mostly do.
>
> Hmm, no prefix or suffix ?
>
Hello,
Let's state that we don't allow absolute paths in RECORD file and see
what we can
do with other paths.
First as a reminder, here's the full list of directories used by
Distutils at installation time.
The "install" command uses five options to decide where to install the files.
The default
2009/7/7 Nick Coghlan :
> For *nix, the obvious use case is installing scripts somewhere like
> /usr/bin or /usr/local/bin.
Using distutils' scripts option, they will end up in : sys.exec_path/bin
Another use case I've found in a distro I've installed this afternoon :
setup(..., data_files=[('/
2009/7/7 Paul Moore :
>
> The RECORD file should contain precisely those files that are created
> as part of the install. That's ultimately the point of the file (for
> ownership queries and uninstallation).
>
> Hmm, on the other hand, if foo.py is in the RECORD file, the
> uninstaller should unins
Paul Moore wrote:
> 2009/7/7 Ben Finney :
>>> - PEP 376 is an opportunity to consider cleanup
>>> - there are some strong supporters of keeping things
>>> setuptools-compatible
>> Your implication seems to be that these two are incompatible. It should
>> be noted that it's possible to clean up, by
At 03:23 PM 7/7/2009 +0200, Tarek Ziadé wrote:
When I started to work on this I didn't realize the gigantic amount of
work and coordination it requires
No one expects the package inquisition. ;-)
___
Python-Dev mailing list
Python-Dev@python.org
htt
Just an idea... suppose that instead of using "real" absolute paths
in the RECORD file for non-local files (scripts, data, etc) we
changed the format to include a "prefix" field, containing something
like LIBDIR, SHARE, SCRIPTS, etc., ala bdist_wininst internals?
Also, we could include a sepa
In Python3 PySys_SetArgv takes (wchar_t **) for the argv, I looked
into converting a (char **) into a (wchar_t **) and while its possible
its lengthy enough not to be trivial, see python.c:18 - char2wcharm(),
its 102 lines with ifdef's and goto's, not including the loop lower
down that loops over t
On Tue, 7 Jul 2009 at 15:26, M.-A. Lemburg wrote:
The merge process itself is more or less clear. What I'm missing
is the agreed upon strategy for applying the patches to the various
branches.
I've seen a few discussions about this, but no final statement
of what strategy to follow and whether h
On Tue, Jul 7, 2009 at 15:32, M.-A. Lemburg wrote:
> Hmm, no prefix or suffix ?
No, not really. hg often shows revision integers as well, but as they
aren't globally consistent, they're of little value in communicating
changeset pointers.
> So we'll always have to write "see deadbeefdeadbeefff fo
Dirkjan Ochtman wrote:
> On Tue, Jul 7, 2009 at 10:16, M.-A. Lemburg wrote:
>> Is there a standard notation for hg revisions that roundup could
>> detect and turn into links (much like it does for svn) ?
>
> [a-f0-9]{12} should mostly do.
Hmm, no prefix or suffix ?
So we'll always have to write
Brett Cannon wrote:
> On Mon, Jul 6, 2009 at 07:51, M.-A. Lemburg wrote:
>
>> Dirkjan Ochtman wrote:
>>> In response to some rumblings on python-committers and just to request
>>> more feedback, a progress report. I know it's long, I've tried to put
>>> to keep it concise and chunked, though.
>>
On Tue, Jul 7, 2009 at 2:52 PM, R. David Murray wrote:
> On Tue, 7 Jul 2009 at 13:05, Paul Moore wrote:
>>
>> 2009/7/7 Ben Finney :
>> [... lots of interesting stuff deleted ...]
>>>
>>> I think it's not the developer's burden to decide *where* such files go;
>>> rather, they should be declaring on
On Tue, 7 Jul 2009 at 13:05, Paul Moore wrote:
2009/7/7 Ben Finney :
[... lots of interesting stuff deleted ...]
I think it's not the developer's burden to decide *where* such files go;
rather, they should be declaring only the *purpose* of these files in
the distribution metadata, and it's up t
2009/7/7 Ben Finney :
>> - PEP 376 is an opportunity to consider cleanup
>> - there are some strong supporters of keeping things
>> setuptools-compatible
>
> Your implication seems to be that these two are incompatible. It should
> be noted that it's possible to clean up, by having a separate (e.g.
2009/7/7 Ben Finney :
[... lots of interesting stuff deleted ...]
> I think it's not the developer's burden to decide *where* such files go;
> rather, they should be declaring only the *purpose* of these files in
> the distribution metadata, and it's up to the site-specific installer
> (possibly as
Paul Moore writes:
> I agree the current situation is a mess. I believe that everything you
> mention is related to setuptools - so essentially, we have the
> situation:
>
> - the existing setuptools format is a mess (at least in the opinion of
> MAL and me :-))
No argument from me on this poin
Paul Moore writes:
> The only cases I know where there is reason for a package to store
> paths outside the package directory are:
I think the *only* files that actually belong in the package directory
are the Python modules inside that package. Other files need to be
easily, and automatically,
Paul Moore wrote:
> 2009/7/6 Nick Coghlan :
> - There are *no* guaranteed absolute locations on Windows, so any such
> oddly-located file would require user interaction to work. Certainly
> bdist_wininst and bdist_msi don't do that.
> - My experiments indicate that bdist_{wininst,msi} are broken wi
2009/7/7 M.-A. Lemburg :
> Well I've added another one above, the pre-built approach :-)
Thanks! That's a lot of help. Are there any public examples, or is
your format only used internally?
Would you expect to use any of the new pkgutil APIs - for example, to
check if a distribution is installed,
2009/7/7 M.-A. Lemburg :
> I think you have to differentiate between packages and applications.
Agreed. I believe that only packages should be considered here.
Applications are the focus of tools like py2exe on Windows, and (AIUI)
things like workingenv. These tools should (will) have their own
ap
On Tue, Jul 7, 2009 at 11:28 AM, M.-A. Lemburg wrote:
>
> Writing an uninstall command really isn't all that hard, provided
> you stick with the standard distutils "python setup.py install"
> dance. The whole packaging approach only complicates things, IMHO.
You can't expect people to keep the dis
Paul Moore wrote:
> 2009/7/7 M.-A. Lemburg :
>> The PEP should take the chance to define not only the
>> directory, but also the complete set of files in there and
>> their format.
>>
>> A typical setuptools dir looks like this:
>>
>> dependency_links.txt
>> namespace_packages.txt
>> not-zip-safe
>
2009/7/7 M.-A. Lemburg :
> The PEP should take the chance to define not only the
> directory, but also the complete set of files in there and
> their format.
>
> A typical setuptools dir looks like this:
>
> dependency_links.txt
> namespace_packages.txt
> not-zip-safe
> PKG-INFO
> requires.txt
> SO
Paul Moore wrote:
>> I know some people are writing to /etc to add their configuration file
>> on the system,
>>
>> So a real-world example under linux would be:
>>
>> setup(..., data_files=[('/etc', ['myconf.cfg'])], ...)
>>
>>
>> That is basically how the examples are shown at:
>>
>> http://docs.
On 6 Jul, 2009, at 20:38, Paul Moore wrote:
- Should distribution names be case insensitive on case insensitive
filesystems? For comparison, module/package names are always case
sensitive even on case insensitive systems.
I'd then go for case sensitive names for distributions as well, just
On Tue, Jul 7, 2009 at 10:33 AM, Paul Moore wrote:
> 2009/7/7 Tarek Ziadé :
>> Unless we define a "drive that contains the python installation" maybe, or
>> the "Program Files" directory
>>
>> would that make sense from a win32 point of view ?
>
> I can't imagine that it would be useful in practic
2009/7/7 Tarek Ziadé :
> Unless we define a "drive that contains the python installation" maybe, or
> the "Program Files" directory
>
> would that make sense from a win32 point of view ?
I can't imagine that it would be useful in practice.
> I know some people are writing to /etc to add their co
On Tue, Jul 7, 2009 at 10:16, M.-A. Lemburg wrote:
> Is there a standard notation for hg revisions that roundup could
> detect and turn into links (much like it does for svn) ?
[a-f0-9]{12} should mostly do.
(Sorry for my absence from the discussion for some time. I'll try to
update the PEP and s
On 6 Jul, 2009, at 9:53, Tarek Ziadé wrote:
2009/7/6 Ronald Oussoren :
I'm -1 on changing the name. For better or worse setuptools is the
elephant
in the room w.r.t. package management and it would IMHO be better
to stay
compatible (even if the stdlib only implements a subset of
setuptools
Nick Coghlan wrote:
> Martin v. Löwis wrote:
>>> I suggest that we also run a version of that redirection filter to remap
>>> the old svn.python.org links in addition to making them accessible
>>> through hg.python.org as Dirkjan proposed.
>> Not sure what links you are talking about, but we also n
2009/7/7 Paul Moore :
> 2009/7/6 Nick Coghlan :
>> I'd add one more question to the list: is allowing backslash separated
>> names in the RECORD file actually a good idea, or would it be better to
>> always use forward slashes?
>
> They do always use forward slashes.
>
>> For the other questions, I
Paul Moore wrote:
> 2009/7/7 Ben Finney :
>> Paul Moore writes:
>>
>>> In fact, the above strongly suggests to me that PEP 376 must NOT
>>> follow setuptools conventions - otherwise, it will end up clashing
>>> with the files setuptools is putting on my system.
>> I think the argument for a separa
2009/7/7 Paul Moore :
> 2009/7/6 P.J. Eby :
>> At 07:38 PM 7/6/2009 +0100, Paul Moore wrote:
>>>
>>> As promised, here are some open questions on PEP 376.
>>>
>>> - Will the public API names be changed from *egginfo* to *metadata*?
>>
>> +1 (FWIW, 'metadata' is what pkg_resources API refers to this
On Tue, Jul 7, 2009 at 12:16 AM, Paul Moore wrote:
>>
>> I believe the idea of having different names in 2.x and 3.x would likely
>> cause too many problems for simple bdist_* installers of modules that
>> use only the common 2.x/3.x language subset, so I'm also -1 on that idea.
>
> That suits me t
2009/7/7 Ben Finney :
> Paul Moore writes:
>
>> In fact, the above strongly suggests to me that PEP 376 must NOT
>> follow setuptools conventions - otherwise, it will end up clashing
>> with the files setuptools is putting on my system.
>
> I think the argument for a separate ‘.pydist’ metadata di
50 matches
Mail list logo
