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
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
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=[('/
ders,xxx,scripts,xxx,install_data,xxx
...
$purelib/some/file
...
How does that sounds ?
Tarek.
--
Tarek Ziadé | http://ziade.org
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
ht
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. ;-
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
On Wed, Jul 8, 2009 at 5:11 PM, P.J. Eby wrote:
> At 01:13 PM 7/8/2009 +0100, Paul Moore wrote:
>>
>> An alternative solution would be for the bdist_xxx commands to ignore
>> the RECORD file generated in the temp area, and build its own on the
>> target machine when the installer is run. This is co
On Thu, Jul 9, 2009 at 12:07 AM, Eric Smith wrote:
> Paul Moore wrote:
>>
>> 2009/7/8 P.J. Eby :
>>>
>>> If it were being driven by setuptools, I'd have just implemented it
>>> myself
>>> and presented it as a fait accompli. I can't speak to Tarek's motives,
>>> but
>>> I assume that, as stated in
On Thu, Jul 9, 2009 at 3:07 AM, P.J. Eby wrote:
> At 09:38 AM 7/9/2009 +0900, Stephen J. Turnbull wrote:
>>
>> Eric Smith writes:
>>
>> > But I think we've veered into metadata that describes what has been
>> > installed. I don't think that's so useful. As I've said, this is
>> private
>> > to t
On Thu, Jul 9, 2009 at 9:18 AM, Paul Moore wrote:
> 2009/7/9 Eric Smith :
>> P.J. Eby wrote:
ISTM that the problem that it solves is uninstall in the absence of
the original installer.
>>>
>>> Or uninstall where the installer is "setup.py install", actually.
>>
>> I think we need to
On Thu, Jul 9, 2009 at 3:42 AM, Sridhar
Ratnakumar wrote:
> Other than easy_install/pip, there is also PyPM which is being developed at
> ActiveState. PyPM is the Python package manager much like what ppm is for
> ActivePerl.
>
Great ! besides the RECORD file, anything remark on the PEP from a
PyP
On Thu, Jul 9, 2009 at 9:09 PM, P.J. Eby wrote:
> At 02:46 PM 7/9/2009 -0400, Tres Seaver wrote:
>>
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>
>> Nick Coghlan wrote:
>> > P.J. Eby wrote:
>> >>> Also,
>> >>> why should the RECORD file be generated at all by bdist* commands?
>> >> bdist
On Fri, Jul 10, 2009 at 8:17 PM, P.J. Eby wrote:
> At 03:31 PM 7/10/2009 +0200, Tarek Ziadé wrote:
>>
>> On Thu, Jul 9, 2009 at 9:09 PM, P.J. Eby wrote:
>> > At 02:46 PM 7/9/2009 -0400, Tres Seaver wrote:
>> >>
>> >> -BEGIN PGP SIGNED MESSAG
distribution name. But then .. most distributions have the same name as
> their primary module/package.
That's it yes: it will be distribution aware. If a module or package
has the same name
than the distribution name, it will make no difference.
>
> Ok, so PEP 345 also specifies the
hen you develop
applications (mid-size and large ones)
and the "good practice" is to avoid any installation of any
distributions in Python itself.
So basically "site-packages" is a distribution location that is
avoided by everyone becau
On Wed, Jul 15, 2009 at 12:17 PM, Michael
Foord wrote:
>> Disclaimer: I've only read the short version, so if some of this is
>> covered in the longer explanation, I apologise now.
>>
>> -1.
>>
>
> I agree. People with versioning issues *should* be using virtualenv.
>
Let's remove site-packages fr
On Wed, Jul 15, 2009 at 4:42 PM, Peter
Hanecak wrote:
> Hello,
>
> thank you David and Benjamin for quick response.
>
> So my subsequent question is: What can help me solve the "writing" part?
Use strings.
Send str(0x7FFF) from the client for example , and get back your
number on server side
On Wed, Jul 15, 2009 at 5:14 PM, Paul Moore wrote:
> 2009/7/15 Tarek Ziadé :
>> On Wed, Jul 15, 2009 at 12:17 PM, Michael
>> Foord wrote:
>>>> Disclaimer: I've only read the short version, so if some of this is
>>>> covered in the longer explanation, I
On Wed, Jul 15, 2009 at 5:16 PM, Joachim König wrote:
> Tarek Ziadé wrote:
>>
>> So basically "site-packages" is a distribution location that is
>> avoided by everyone because it doesn't
>> know how to handle multiple versions.
>
> I think you overra
2009/7/15 P.J. Eby :
[...]
> So if politics demands that it be rejected by association with "setuptools",
> then just search-and-replace the API, PEP 8-ify it, call it something
> different, and lie to everyone about where it came from. I won't tell if
> you won't. ;-)
While setuptools did addre
2009/7/15 Sridhar Ratnakumar :
> On Wed, 15 Jul 2009 02:01:24 -0700, Tarek Ziadé
> wrote:
>
>>>> get_installed_files(local=False) -> iterator of (path, md5, size)
>>>
>>> Will this also return the directories /created/ during the installation?
>&
On Sun, Jul 19, 2009 at 3:08 PM, R. David Murray wrote:
> On Sun, 19 Jul 2009 at 16:07, Nick Coghlan wrote:
>>
>> David Lyon wrote:
>>>
>>> So it isn't clear why you want to remove the thing that you are
>>> advocating works so great
>>
>> Jim was quoting someone *else* that had suggested remov
this may or may not have changed in terms of
> what the (now) distutils maintainer thinks.
>
I don't recall those repeated attempts , but I've been around for less
than two years.
You are very welcome to come in the Distutils-SIG ML to discuss these matters.
I'm moving th
discussions, to be talked in distutils-SIG:
1/ static metadata using a setup.cfg.in (the current one)
2/ changes that will occur in PEP 345, to include requirement definitions
Regards
Tarek
--
Tarek Ziadé | http://ziade.org | オープンソースの岩！
___
Python-Dev m
in a restricted and secured manner.
So there's no need to run third-party code anymore.
Possible use cases:
- setup.cfg is published on PyPI. Packages managers like easy_install
or pip will be able to list all the distributions needed and their
versions for installing a distribution
On Tue, Sep 22, 2009 at 4:02 PM, Chris Withers wrote:
>> [setup:python_version == '2.4' or python_version == '2.5']
>> requires: some_package
>
> As was brought up on the distutils list, this seems unnecessarily
> complicated.
>
> Other, simpler, solutions were proposed:
>
> http://mail.pyth
2009/9/22 P.J. Eby :
> At 03:21 PM 9/22/2009 +0200, Tarek Ziadé wrote:
>>
>> Hello Here's a wrapup of the Distutils-SIG discussion we had on the
>> "static metadata" topic. I realize that it's a good thing to send in.
>> python-dev such wrapup
ted in favor of '=' only, Distutils will be fine with
that change.
I would be +1 for its deprecation
Tarek
--
Tarek Ziadé | http://ziade.org | オープンソースはすごい!
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/
On Tue, Sep 22, 2009 at 8:12 PM, Tarek Ziadé wrote:
> If you are talking about another solution than using setup.cfg with
> conditional
> expressions, please start a new thread
(in Distutils SIG)
___
Python-Dev mailing list
Python-Dev@python
o build a
requires.txt file when you install a package or create a binary distribution.
The later is not related to what we want to do, or if it is, please
refine your proposal
and make it clear at Distutils-SIG.
Tarek
--
Tarek Ziadé | http://ziade.org | オープンソースはすごい!
__
eshedding.
- explaining that os.uname() contains irrelevant infos and we
shouldn't add it as-is in the
execution context is not bikeshedding (see Ronald last mail in the thread)
Please go back to the thread at distutils-SIG and list all points in
the proposal
that seems to you as non-b
? and that I need to
take some decisions to move distutils on ?
Especially for this topic. If you take the time to read everything you'll see
that there were no real alternative design proposed, and that I am
just working out
the details because I mai
On Wed, Sep 23, 2009 at 4:04 PM, Stephen J. Turnbull wrote:
> I did offer a concrete criterion for an individual's participation in
> a "internal consensus": that you expect that they will adopt the new
> features of distutils as a foundation for their own distribution
> systems, or at least not i
On Wed, Sep 23, 2009 at 7:08 PM, Michael Foord
wrote:
> Note that Activestate also have a fledgling package management system for
> Python (unreleased yet I *believe*) so it is probably worth reaching out to
> them as well.
Yes I didn't mention it because the project is private afaik. I'll ask
th
ou say "Tarek appears" it is something I
have never said but rather something you are thinking like being the truth.
Now for the Distribute work , your patches are very welcome. It s a
community project.
On Sep 23, 2009 10:47 PM, "P.J. Eby" wrote:
At 07:00 PM 9/23/2009 +020
Fine with me. Let's move forward.
On Sep 23, 2009 11:27 PM, "Antoine Pitrou" wrote:
P.J. Eby telecommunity.com> writes: > > Hell, I *support* the bulk
of Tarek's setup.cfg p...
Ok, so Tarek and Philip, are you both ok that those little disagreements
should
belong to the past now? :)
Philip did
On Mon, Oct 5, 2009 at 2:06 PM, Ned Deily wrote:
> Assuming that distutils is not changed in a forthcoming 2.6.4
Since the changes made in Distutils were bug fixes that kept all public API
backward compatible, I don't see why this should be changed.
Setuptools development has been discontinued f
on-Dev@python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> http://mail.python.org/mailman/options/python-dev/ziade.tarek%40gmail.com
>
--
Tarek Ziadé | http://ziade.org | オープンソースはすごい! | 开源传万世，因有你参与
___
Python-Dev
On Mon, Oct 5, 2009 at 3:32 PM, Barry Warsaw wrote:
> On Oct 5, 2009, at 8:22 AM, Tarek Ziadé wrote:
>
>>> I'm not proposing to debate the merits of all of the options here.
>>> However, if a 2.6.4 release is to be pushed out quickly for other
>>> reasons,
On Mon, Oct 5, 2009 at 4:32 PM, Barry Warsaw wrote:
> On Oct 5, 2009, at 10:17 AM, Tarek Ziadé wrote:
>
>>> If setuptools can be made to work with Python 2.6.3 /and/ earlier
>>> versions
>>> of Python 2.6.x, then it should be patched and an update released. If
&g
On Mon, Oct 5, 2009 at 4:27 PM, M.-A. Lemburg wrote:
> Tarek Ziadé wrote:
>> Now I am astonished that we are talking about reverting changes in
>> Distutils that were done for bugfixes, for a third party package that
>> does monkey
>> patches on Distutils.
>>
>
On Mon, Oct 5, 2009 at 4:40 PM, wrote:
>
> Tarek> That's why we have forked and created Distribute, to provide bug
> Tarek> fixes.
>
> I suspect you might need to publicize this a bit better. The first I heard
> of Distribute or non-responsiveness of PJE regarding setuptools was this
> thr
On Mon, Oct 5, 2009 at 5:26 PM, M.-A. Lemburg wrote:
> Tarek Ziadé wrote:
>> On Mon, Oct 5, 2009 at 4:27 PM, M.-A. Lemburg wrote:
>>> Tarek Ziadé wrote:
>>>> Now I am astonished that we are talking about reverting changes in
>>>> Distutils that were do
On Mon, Oct 5, 2009 at 6:44 PM, Antoine Pitrou wrote:
>
> The only question is, given that 2.6.x is supposed to be a bug-fix branch, do
> we
> want to fix that incompatibility with a widely deployed existing piece of
> software? Whether or not the incompatibility is legitimate (i.e., whether
> se
On Mon, Oct 5, 2009 at 7:06 PM, M.-A. Lemburg wrote:
> Tarek Ziadé wrote:
>> On Mon, Oct 5, 2009 at 6:44 PM, Antoine Pitrou wrote:
>>>
>>> The only question is, given that 2.6.x is supposed to be a bug-fix branch,
>>> do we
>>> want to fix that in
having other formats and ways to query them
in a second move.
That's why I don't think its the right time to add a bdist_egg command
in Distutils, until PEP 376 is
fully defined (and maybe extended to support several format).
Tarek
--
Tarek Ziadé | http://ziade.org | オープンソースはすごい! | 开源
PEP will be finished before 2.7 is out.
Notice that PEP 382 (namespaced packages) is already a great step forward.
(by the way, I thought this one was accepted, shouldn't its status updated ?)
Tarek
--
Tarek Ziadé | http://ziade.org | オープンソースはすごい! | 开源传万世，因有你参与
On Wed, Oct 7, 2009 at 10:43 PM, Sridhar Ratnakumar
wrote:
> PyPM client relies on pkg_resources *only*[1]. Specifically for
>
> 1) the version comparison algorithm:
[...]
>
> 2) parsing the "install_requires" string:
>
[...]
>
> Both these features are definitely worthy of addition to stdlib but
he way its works.
I would like to create a new site-packages format that can contains
several versions of the same distribution, and :
- a special import system using importlib that would automatically
pick the latest version, thanks to PEP 376.
- an API to force at runtime a specific version (that
On Thu, Oct 8, 2009 at 9:35 AM, M.-A. Lemburg wrote:
> BTW: Who would I need to contact for the PyPI side to work out
> an upload_url distutils command ?
I am not sure to understand. How upload_url will differ from the
register command
that let you upload metadata at PyPI ?
Tarek
___
On Thu, Oct 8, 2009 at 10:38 AM, M.-A. Lemburg wrote:
> Tarek Ziadé wrote:
>> On Thu, Oct 8, 2009 at 9:35 AM, M.-A. Lemburg wrote:
>>> BTW: Who would I need to contact for the PyPI side to work out
>>> an upload_url distutils command ?
>>
>> I am not
On Thu, Oct 8, 2009 at 10:56 AM, Paul Moore wrote:
>
> +1
>
> This addresses my biggest concern with the way PEP 376 was going
> (largely prompted by my suggestions, so I'll take the blame for this!)
> which was that PEP 376 was trying to define list/uninstall methods for
> package formats (i.e. z
On Thu, Oct 8, 2009 at 11:42 AM, David Cournapeau wrote:
> On Thu, Oct 8, 2009 at 5:31 PM, Tarek Ziadé wrote:
>
>> = Virtualenv and the multiple version support in Distribute =
>>
>> (I am not saying "We" here because this part was not discussed yet
>> wi
added.
>
> I hope that comment means "no new bdist_* command will be added
> *right now*". It's well possible to create new bdist_* commands
> that don't rely on external tool chains or only on ones that
> don't change often.
>
&
On Thu, Oct 8, 2009 at 1:17 PM, Christian Heimes wrote:
[...]
> The altered user site directories are:
>
> CPython:
> ~/.local/lib/python2.6/site-packages
> %APPDATA%/Python/Python26
>
> IronPython:
> ~/.local/lib/ironpython2.6/site-packages
> %APPDATA%/Python/IronPython26
>
> Jython:
> ~/.lo
On Thu, Oct 8, 2009 at 4:55 PM, M.-A. Lemburg wrote:
> OTOH, the register command sends the meta-data directly to
> the PyPI database, so it doesn't even need another file
> for storing away the meta data.
>
> Unless I'm missing something important (which I probably am),
> the only added value of
On Thu, Oct 8, 2009 at 11:28 PM, Ned Deily wrote:
[..]
> So, without some other intervention, users will continue to follow the
> instructions with those hundreds of packages (or on those thousands of
> websites) and manually or automatically try to install setuptools.
I think this will be in the
On Fri, Oct 9, 2009 at 1:11 AM, kiorky wrote:
>
>
> Tarek Ziadé a écrit :
>
>> The choice to deprecate easy_install in 0.7 is done because the Pip project
>> is not far to meet all uses cases easy_install users have, and we're betting
>> on the fact that
*why* it got to a certain links. These are the two
> things I can think of where the index code in pip is tied to pip, and
> why it would be hard to use an external system.
OK. Maybe this particular package could be used by another tool
that needs to work with PyPI. It will also include a s
On Fri, Oct 9, 2009 at 10:20 AM, M.-A. Lemburg wrote:
>
> I know that the issue tracker for PyPI is (still) on SF, but
> development appear to happen elsewhere and I can't find any
> contact information on the PyPI web pages.
Everything is provided here:
http://wiki.python.org/moin/CheeseShopDev
On Fri, Oct 9, 2009 at 5:01 PM, Chris Withers wrote:
> Guido van Rossum wrote:
>>
>> I'm saying that I don't expect setuptools 0.7 to appear before Tarek's
>> Distribute is mature and in widespread use. IOW I support Tarek's fork
>> and suggest nobody hold their breath waiting for setuptools 0.7.
On Fri, Oct 9, 2009 at 5:32 PM, Chris Withers wrote:
>
>> So I am adding this in Distutils for 2.7.
>
> NB: There was no consensus on this "micro-language" on distutils-sig.
> While I suspect I don't care as none of my packages rely on anything other
> than other python packages, others did care,
On Fri, Oct 9, 2009 at 5:37 PM, Chris Withers wrote:
> Tarek Ziadé wrote:
>>
>> Some new commands are added there, when they are helpful and don't
>> interact with the rest. I am thinking
>> about "upload_docs" that let you upload documentation to Py
On Fri, Oct 9, 2009 at 5:42 PM, Chris Withers wrote:
> Tarek Ziadé wrote:
>>
>> - The code is splitted in many packages and might be distributed under
>> several distributions.
>>
>> - distribute.resources: that's the old pkg_resources...
> Why not j
On Fri, Oct 9, 2009 at 6:03 PM, Chris Withers wrote:
> Tarek Ziadé wrote:
>>>
>>> How about helping the author of that extension make it work with
>>> Distribute
>>> or just get that implementation into Distutils core instead?
>>
>> It's th
On Fri, Oct 9, 2009 at 6:08 PM, Chris Withers wrote:
>
> Shame there hasn't been any discussion of this recently on distutils-sig...
We had many discussion on this already. I don't mind to have another
round, on the contrary,
but let's do it in Distutils-SIG
We are making a lot of noise now in P
On Sun, Oct 11, 2009 at 1:26 PM, Ben Finney wrote:
> "Stephen J. Turnbull" writes:
>
>> Trimming can be a PITA if you're using a crummy MUA
>
> How so? It merely requires the ability to navigate up and down by lines,
> and to select and delete text. I've used some very crummy MUAs, but the
> abil
On Thu, Oct 8, 2009 at 2:56 PM, Paul Moore wrote:
> In this context, eggs are "merely" the first (and most important)
[..]
> example of a format extension, and so should drive the development of
> a standard.
>
> To summarise:
>
> I believe that we need a statement of direction on the (zipped) egg
On Sun, Oct 11, 2009 at 7:27 PM, Steven Bethard
wrote:
>> I am working with Tarek to keep Windows issues (and in particular this
>> one) on the agenda. It's quite hard at times, as getting a
>> representative sample of Windows users' preferences/requirements is
>> difficult at best (Windows users
On Tue, Oct 13, 2009 at 4:52 PM, P.J. Eby wrote:
> At 08:27 AM 10/13/2009 -0400, Barry Warsaw wrote:
>>
>> Are we on track to release 2.6.4 final this Sunday or do we need
>> another rc?
>>
>> Yesterday, Tarek committed another setuptools related fix and said
>> that he was going to run a bunch of
On Tue, Oct 13, 2009 at 5:30 PM, P.J. Eby wrote:
>
> One identical to test_build_ext_path_with_os_sep, but that explicitly uses a
> '/' (rather than os.sep) will identify the problem I'm referring to, when
> run on Windows.
>
> It's common practice to use /-separated paths in setup scripts, regard
On Tue, Oct 13, 2009 at 5:16 PM, Tarek Ziadé wrote:
> On Tue, Oct 13, 2009 at 4:52 PM, P.J. Eby wrote:
>> At 08:27 AM 10/13/2009 -0400, Barry Warsaw wrote:
>>>
>>> Are we on track to release 2.6.4 final this Sunday or do we need
>>> another rc?
>&g
Hello,
Since the addition of PEP 370, (per-user site packages), site.py and
distutils/command/install.py are *both* providing the various
installation directories for Python,
depending on the system and the Python version.
We have also started to discuss lately in various Mailing Lists the
additi
M.-A. Lemburg wrote:
> +1
On Oct 28, 2009, at 7:02 AM, Michael Foord wrote:
> Also +1. It seems like this would make things easier for the alternative
> implementations.
On Wed, Oct 28, 2009 at 3:30 PM, sstein...@gmail.com
wrote:
> +1
Ok then I'll work on a patch for that change and start an i
On Wed, Oct 28, 2009 at 7:05 PM, Tarek Ziadé wrote:
> Ok then I'll work on a patch for that change and start an issue about it soon.
As I expected, being able to provide all those paths pulls a lot of
other stuffs out of distutils.
In fact, almost all the APIs that are located in d
On Thu, Nov 5, 2009 at 11:29 PM, David Lyon wrote:
[...]
>
> But if you put all these PEPs together, implementing all the new features
> can't come to more than 300 lines of code...
>
> Since we hardly got anywhere on them in 2009, it will be interesting to
> see how much of it gets done in 2010.
2009/11/6 David Lyon :
[..]
> Here are the references to the discussions from distutils-sig. In these
> references you'll see that my interaction with the list was not grumpy
> but was entirely positive. I feel that I got a fair hearing on distutils
> list and I had a number of supporters to my pro
Hi,
I was wondering what's the status of PEP 382. Is anyone (MvL?) is
going to start to work on its implementation for Python 2.7/3.2
inclusion ?
Regards
Tarek
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/pyt
ule a template, and inject
at its beginning new values extracted from Makefile and pyconfig.h.
This could happen when "configure" is called,
Regards,
Tarek
--
Tarek Ziadé | http://ziade.org | オープンソースはすごい! | 开源传万世，因有你参与
___
Python-Dev mailing
2009/11/15 "Martin v. Löwis" :
>> http://bugs.python.org/issue4359 reminds me that Distutils reads build
>> files like Makefile or pyconfig.h to get some environment
>> variables through the sysconfig module at *runtime*.
>>
>> This cannot work on all platforms, when our Makefile is not shipped
>>
On Sun, Nov 15, 2009 at 2:41 AM, Arfrever Frehtes Taifersar Arahesis
wrote:
[..]
>>
>> This could happen when "configure" is called,
>
> It seems to be a good idea. You should create a .py.in file and use
> AC_SUBST and AC_CONFIG_FILES macros in configure.in.
I need to investigate on these, thx
2009/11/15 "Martin v. Löwis" :
>> The problem is that the main python distribution ("python") is not
>> working as advertised since
>> it contains distutils, which requires "python-devel" to work.
>>
>> This implies that "python" has a dependency on "python-devel", which
>> does not make sense
>> a
On Sun, Nov 15, 2009 at 3:35 AM, Christian Heimes wrote:
[..]
> Do we really want to change distutils to solve a problem of a third
> party packaging system when the problem was created by the very same
> third party in the first place? In other words: Should you spend your
> precious development
On Sun, Nov 15, 2009 at 4:02 AM, Terry Reedy wrote:
> Christian Heimes wrote:
>>
>> Tarek Ziadé wrote:
>>>
>>> Hello,
>>>
>>> http://bugs.python.org/issue4359 reminds me that Distutils reads build
>>> files like Makefile or pyconfig.h
On Sat, Nov 14, 2009 at 4:34 PM, Arc Riley wrote:
>
>> +1
>>
>> Having a "Repository-URL", "Repository-Browse-URL" and a
>> "Bug-Tracker-URL" field in PyPI would be a lot more usefule then
>> comments and ratings.
>>
>
> +1
You mean in the Metadata ? We are currenty working on adding fields in th
On Mon, Nov 16, 2009 at 8:15 PM, Toshio Kuratomi wrote:
[..]
> I've brought the issue of Makefile and pyconfig.h being needed for distutils
> to the attention of every new Fedora python maintainer since the package
> split was made. The current maintainer, David Malcolm, agrees that
> distutils.s
On Mon, Nov 16, 2009 at 10:09 PM, David Malcolm wrote:
[..]
>>
>> $ dpkg -S /usr/lib/python2.5/config/Makefile
>> python2.5: /usr/lib/python2.5/config/Makefile
> For what it's worth, this is fixed in Fedora as of python-2.6.4-2.fc13 ;
> the bug tracking it was:
> https://bugzilla.redhat.com/show_b
On Thu, Nov 19, 2009 at 11:04 AM, Antoine Pitrou wrote:
> Tarek Ziadé gmail.com> writes:
>>
>> So what I am proposing is to inject those values in a private dict in
>> the new sysconfig.py module,
>> that can be read through the get_config_vars / get_config_v
On Thu, Nov 19, 2009 at 12:04 PM, M.-A. Lemburg wrote:
[..]
> BTW: There's already a Tools/scripts/h2py.py we could use for
> converting pyconfig.h into a Python file.
Good to know,
> For the Makefile
> we could use the distutils Makefile parser to add the extra
> values.
Yes, there's also a py
On Sun, Nov 29, 2009 at 6:32 PM, C. Titus Brown wrote:
> Hi all,
>
> /trunk test_distutils is failing with the following error on Mac OS X 10.5:
>
> Here's the error:
>
> test_distutils
> test test_distutils failed -- Traceback (most recent call last):
> File
> "/private/tmp/tmp8UfLPT/python27/Lib
On Sun, Nov 29, 2009 at 8:55 PM, Ned Deily wrote:
> In article <20091129184722.ga32...@idyll.org>,
> "C. Titus Brown" wrote:
>> On Sun, Nov 29, 2009 at 06:43:50PM +, Mark Dickinson wrote:
>> > I'm not seeing the test_distutils failure you report on my own
>> > 10.5 machine, for some reason.
ill get on distutils-sig, and in the interests of avoiding months of
further discussion which won't take things any further, I propose to
allow final comments from python-dev and then look for a final
decision.
Regards
Tarek
--
Tarek Ziadé | http://ziade.org | オープンソースはすごい
On Tue, Dec 8, 2009 at 8:45 PM, Terry Reedy wrote:
> Tarek Ziadé wrote:
>>
>> Hello,
>>
>> On behalf of the Distutils-SIG, I would like to propose PEP 386 for
>> inclusion in the sdtlib, and have a final discussion here on
>> Python-dev.
>>
>&g
On Wed, Dec 9, 2009 at 5:53 AM, Michael Mysinger wrote:
> More English language fixes:
I have just applied them. Thanks.
Tarek
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mai
On Thu, Dec 10, 2009 at 9:44 AM, Malthe Borch wrote:
[..]
> Great work, Tarek. I think you've managed to establish a good body of
> knowledge on this and the proposal seems sound.
Thanks :)
>
> That said, I think the terms ``LooseVersion`` and ``StrictVersion`` are less
> than optimal. Really, w
On Thu, Dec 10, 2009 at 10:44 AM, Floris Bruynooghe
wrote:
[..]
>> N.N[.N]+[{abc}N[.N]+][.postN][.devN]
>>
>> Notice that the last two +'s are gone, and overall I think this is more
>> consistent psuedo-code.
>
> That's quite readable and more consistent then the original
> pseudo-code, I like it.
On Fri, Dec 11, 2009 at 1:14 AM, Ben Finney wrote:
> Tarek Ziadé writes:
>
>> I believe that the current situation is as close to consensus as we
>> will get on distutils-sig, and in the interests of avoiding months of
>> further discussion which won't take thi
On Fri, Dec 11, 2009 at 6:15 AM, Ben Finney wrote:
[..]
>
> No, the PEP document itself should either contain the questions and
> answers, or contain a link to the discussion along with a brief summary
> of what it was about and a explicit statement of its outcome.
Ok then, I'll add a section sum
On Fri, Dec 11, 2009 at 11:23 AM, Nick Coghlan wrote:
> Darren Dale wrote:
>> On Thu, Dec 10, 2009 at 8:54 AM, Antoine Pitrou wrote:
>>> Tarek Ziadé gmail.com> writes:
>>>> Do you have a better suggestion ? I was thinking about StandardVersion
>>>&g
On Fri, Dec 11, 2009 at 6:15 AM, Ben Finney
[..]
>
> Yes, I'm referring to the discussion that were had over “why do we want
> special keywords that mess with the default alphanumerical ordering of
> version string components?” discussion.
>
> That needs to be addressed in the PEP, since it's germa
101 - 200 of 475 matches
Mail list logo
