From setuptools at bugs.python.org  Sun Jan  3 11:42:55 2010
From: setuptools at bugs.python.org (techtonik)
Date: Sun, 03 Jan 2010 10:42:55 +0000
Subject: [Distutils] [issue101] Traceback when installing readline
In-Reply-To: <1262515375.34.0.493585714196.issue101@psf.upfronthosting.co.za>
Message-ID: <1262515375.34.0.493585714196.issue101@psf.upfronthosting.co.za>


New submission from techtonik <techtonik at gmail.com>:

Python 2.6 on Vista

C:\Python26\Scripts>python -m easy_install readline
Searching for readline
Reading http://pypi.python.org/simple/readline/
Reading http://www.python.org/
Best match: readline 2.6.4
Downloading http://pypi.python.org/packages/source/r/readline/readline-2.6.4.tar.gz#md5=7568e8b78f383443ba57c9afec6f4285
Processing readline-2.6.4.tar.gz
Running readline-2.6.4\setup.py -q bdist_egg --dist-dir c:\users\myuser\appdata\local\temp\easy_install-yxalev\readline-2.6.4\egg-dist-tmp-7rtcal
The system cannot find the path specified.
Traceback (most recent call last):
  File "C:\Python26\lib\runpy.py", line 122, in _run_module_as_main
    "__main__", fname, loader, pkg_name)
  File "C:\Python26\lib\runpy.py", line 34, in _run_code
    exec code in run_globals
  File "C:\Python26\lib\site-packages\setuptools-0.6c11-py2.6.egg\easy_install.py", line 5, in <module>
  File "C:\Python26\lib\site-packages\setuptools-0.6c11-py2.6.egg\setuptools\command\easy_install.py", line 1712, in main
  File "C:\Python26\lib\site-packages\setuptools-0.6c11-py2.6.egg\setuptools\command\easy_install.py", line 1700, in with_ei_usage
  File "C:\Python26\lib\site-packages\setuptools-0.6c11-py2.6.egg\setuptools\command\easy_install.py", line 1716, in <lambda>
  File "C:\Python26\lib\distutils\core.py", line 152, in setup
    dist.run_commands()
  File "C:\Python26\lib\distutils\dist.py", line 975, in run_commands
    self.run_command(cmd)
  File "C:\Python26\lib\distutils\dist.py", line 995, in run_command
    cmd_obj.run()
  File "C:\Python26\lib\site-packages\setuptools-0.6c11-py2.6.egg\setuptools\command\easy_install.py", line 211, in run
  File "C:\Python26\lib\site-packages\setuptools-0.6c11-py2.6.egg\setuptools\command\easy_install.py", line 446, in easy_install
  File "C:\Python26\lib\site-packages\setuptools-0.6c11-py2.6.egg\setuptools\command\easy_install.py", line 476, in install_item
  File "C:\Python26\lib\site-packages\setuptools-0.6c11-py2.6.egg\setuptools\command\easy_install.py", line 655, in install_eggs
  File "C:\Python26\lib\site-packages\setuptools-0.6c11-py2.6.egg\setuptools\command\easy_install.py", line 930, in build_and_install
  File "C:\Python26\lib\site-packages\setuptools-0.6c11-py2.6.egg\setuptools\command\easy_install.py", line 919, in run_setup
  File "C:\Python26\lib\site-packages\setuptools-0.6c11-py2.6.egg\setuptools\sandbox.py", line 62, in run_setup
  File "C:\Python26\lib\site-packages\setuptools-0.6c11-py2.6.egg\setuptools\sandbox.py", line 105, in run
  File "C:\Python26\lib\site-packages\setuptools-0.6c11-py2.6.egg\setuptools\sandbox.py", line 64, in <lambda>
  File "setup.py", line 93, in <module>
AttributeError: 'module' object has no attribute 'symlink'

----------
messages: 484
nosy: techtonik
priority: bug
status: unread
title: Traceback when installing readline

_______________________________________________
Setuptools tracker <setuptools at bugs.python.org>
<http://bugs.python.org/setuptools/issue101>
_______________________________________________

From techtonik at gmail.com  Sun Jan  3 13:03:35 2010
From: techtonik at gmail.com (anatoly techtonik)
Date: Sun, 3 Jan 2010 14:03:35 +0200
Subject: [Distutils] test coverage for setuptools
Message-ID: <d34314101001030403k299dfd8ble82d5176dd3554f0@mail.gmail.com>

Hello,

Where can I see test coverage results for setuptools package?
I've got two tracebacks in last week after upgrading and that seems to
be too much.
I'd like to see if there are any tests for failing piece to see why
they might fail before digging further.

Bye!
-- 
anatoly t.

From techtonik at gmail.com  Sun Jan  3 13:14:03 2010
From: techtonik at gmail.com (anatoly techtonik)
Date: Sun, 3 Jan 2010 14:14:03 +0200
Subject: [Distutils] pkg_resources get Distribution by module name
Message-ID: <d34314101001030414r1683b9e7p524f6cee0a15160c@mail.gmail.com>

Hello,

If there any way to get Distribution information given the module name
like 'trac.admin.web_ui'  in setuptools?

There is a problem to extract information about exact distribution
name and version when module is already imported in application (Trac
plugins).

Thanks.
-- 
anatoly t.

From ziade.tarek at gmail.com  Sun Jan  3 21:22:15 2010
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Sun, 3 Jan 2010 21:22:15 +0100
Subject: [Distutils] test coverage for setuptools
In-Reply-To: <d34314101001030403k299dfd8ble82d5176dd3554f0@mail.gmail.com>
References: <d34314101001030403k299dfd8ble82d5176dd3554f0@mail.gmail.com>
Message-ID: <94bdd2611001031222v35640d40s52b070bee5940998@mail.gmail.com>

On Sun, Jan 3, 2010 at 1:03 PM, anatoly techtonik <techtonik at gmail.com> wrote:
> Hello,
>
> Where can I see test coverage results for setuptools package?
> I've got two tracebacks in last week after upgrading and that seems to
> be too much.
> I'd like to see if there are any tests for failing piece to see why
> they might fail before digging further.

You can run "python setup.py test" on both Distribute and Setuptools. This will
use the test command and run all tests

Tarek

From ziade.tarek at gmail.com  Sun Jan  3 21:28:19 2010
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Sun, 3 Jan 2010 21:28:19 +0100
Subject: [Distutils] pkg_resources get Distribution by module name
In-Reply-To: <d34314101001030414r1683b9e7p524f6cee0a15160c@mail.gmail.com>
References: <d34314101001030414r1683b9e7p524f6cee0a15160c@mail.gmail.com>
Message-ID: <94bdd2611001031228h42e09527r8c881aa0b2e7599e@mail.gmail.com>

On Sun, Jan 3, 2010 at 1:14 PM, anatoly techtonik <techtonik at gmail.com> wrote:
> Hello,
>
> If there any way to get Distribution information given the module name
> like 'trac.admin.web_ui' ?in setuptools?
>
> There is a problem to extract information about exact distribution
> name and version when module is already imported in application (Trac
> plugins).

I am not sure exactly what you are trying to do, but :

If your trac plugin was done using entry points (as it says at
http://trac.edgewall.org/wiki/TracDev/PluginDevelopment), this means
that you can
use the iter_entry_points API from pkg_resources: You will get a
EntryPoint object that contains a dist attribute, pointing to the
distribution infos.


>
> Thanks.
> --
> anatoly t.
> _______________________________________________
> Distutils-SIG maillist ?- ?Distutils-SIG at python.org
> http://mail.python.org/mailman/listinfo/distutils-sig
>



-- 
Tarek Ziad? | http://ziade.org

From techtonik at gmail.com  Mon Jan  4 14:53:46 2010
From: techtonik at gmail.com (anatoly techtonik)
Date: Mon, 4 Jan 2010 15:53:46 +0200
Subject: [Distutils] test coverage for setuptools
In-Reply-To: <94bdd2611001031222v35640d40s52b070bee5940998@mail.gmail.com>
References: <d34314101001030403k299dfd8ble82d5176dd3554f0@mail.gmail.com>
	<94bdd2611001031222v35640d40s52b070bee5940998@mail.gmail.com>
Message-ID: <d34314101001040553l35899b63k416de30b87820bc5@mail.gmail.com>

On Sun, Jan 3, 2010 at 10:22 PM, Tarek Ziad? <ziade.tarek at gmail.com> wrote:
>>
>> Where can I see test coverage results for setuptools package?
>> I've got two tracebacks in last week after upgrading and that seems to
>> be too much.
>> I'd like to see if there are any tests for failing piece to see why
>> they might fail before digging further.
>
> You can run "python setup.py test" on both Distribute and Setuptools. This will
> use the test command and run all tests

By test coverage results I mean publicly available reports about
percentage of code covered by tests that were run by testing
buildbots. See examples:
http://www.eclipse.org/pde/pde-api-tools/coverage/20091126/eclemma.html
http://eigenclass.org/static/rcov-sample-report/
http://web.archive.org/web/20070403133248/http://seb.dbzteam.com/pub/urllib2.py.html

-- 
anatoly t.

From techtonik at gmail.com  Mon Jan  4 15:03:34 2010
From: techtonik at gmail.com (anatoly techtonik)
Date: Mon, 4 Jan 2010 16:03:34 +0200
Subject: [Distutils] pkg_resources get Distribution by module name
In-Reply-To: <94bdd2611001031228h42e09527r8c881aa0b2e7599e@mail.gmail.com>
References: <d34314101001030414r1683b9e7p524f6cee0a15160c@mail.gmail.com>
	<94bdd2611001031228h42e09527r8c881aa0b2e7599e@mail.gmail.com>
Message-ID: <d34314101001040603y45750b53t36ad3dbaa3d4c339@mail.gmail.com>

On Sun, Jan 3, 2010 at 10:28 PM, Tarek Ziad? <ziade.tarek at gmail.com> wrote:
>>
>> If there any way to get Distribution information given the module name
>> like 'trac.admin.web_ui' ?in setuptools?
>>
>> There is a problem to extract information about exact distribution
>> name and version when module is already imported in application (Trac
>> plugins).
>
> I am not sure exactly what you are trying to do, but :
>
> If your trac plugin was done using entry points (as it says at
> http://trac.edgewall.org/wiki/TracDev/PluginDevelopment), this means
> that you can
> use the iter_entry_points API from pkg_resources: You will get a
> EntryPoint object that contains a dist attribute, pointing to the
> distribution infos.

Thanks. Already followed this way. Entrypoints is only one way to
discover plugins - they will work also if imported directly (there is
"plugins" folder in every user site setup). When plugin is imported,
everything we have is a name of its class, its module name and path to
module file.

I need to figure out if given module belongs to any setuptools
Distribution to know if it possible to extract any useful information
from it to display to user in administration panel.

-- 
anatoly t.

From ziade.tarek at gmail.com  Mon Jan  4 15:06:13 2010
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Mon, 4 Jan 2010 15:06:13 +0100
Subject: [Distutils] test coverage for setuptools
In-Reply-To: <d34314101001040553l35899b63k416de30b87820bc5@mail.gmail.com>
References: <d34314101001030403k299dfd8ble82d5176dd3554f0@mail.gmail.com>
	<94bdd2611001031222v35640d40s52b070bee5940998@mail.gmail.com>
	<d34314101001040553l35899b63k416de30b87820bc5@mail.gmail.com>
Message-ID: <94bdd2611001040606k5a889f53nbf8b8afeaf2900d@mail.gmail.com>

On Mon, Jan 4, 2010 at 2:53 PM, anatoly techtonik <techtonik at gmail.com> wrote:
> On Sun, Jan 3, 2010 at 10:22 PM, Tarek Ziad? <ziade.tarek at gmail.com> wrote:
>>>
>>> Where can I see test coverage results for setuptools package?
>>> I've got two tracebacks in last week after upgrading and that seems to
>>> be too much.
>>> I'd like to see if there are any tests for failing piece to see why
>>> they might fail before digging further.
>>
>> You can run "python setup.py test" on both Distribute and Setuptools. This will
>> use the test command and run all tests
>
> By test coverage results I mean publicly available reports about
> percentage of code covered by tests that were run by testing
> buildbots. See examples:
> http://www.eclipse.org/pde/pde-api-tools/coverage/20091126/eclemma.html
> http://eigenclass.org/static/rcov-sample-report/
> http://web.archive.org/web/20070403133248/http://seb.dbzteam.com/pub/urllib2.py.html

For Distribute I have my own but they are not public (yet). I don't
think Setuptools has any.

Although, It's easy to run your own using Coverage (see at pypi)

FYI, in Setuptools, the relevant parts (bdist_egg, easy_install,
package_index) of the code are not very well covered (around 20% in
average). There's a doctest for pkg_resources that does a better job.
Distribute is slightly higher.

If you are interested in having a public one, I can set if up for Distribute

Tarek

From ziade.tarek at gmail.com  Mon Jan  4 15:18:24 2010
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Mon, 4 Jan 2010 15:18:24 +0100
Subject: [Distutils] pkg_resources get Distribution by module name
In-Reply-To: <d34314101001040603y45750b53t36ad3dbaa3d4c339@mail.gmail.com>
References: <d34314101001030414r1683b9e7p524f6cee0a15160c@mail.gmail.com>
	<94bdd2611001031228h42e09527r8c881aa0b2e7599e@mail.gmail.com>
	<d34314101001040603y45750b53t36ad3dbaa3d4c339@mail.gmail.com>
Message-ID: <94bdd2611001040618r5db924a7hd9e1bdf74a216c39@mail.gmail.com>

On Mon, Jan 4, 2010 at 3:03 PM, anatoly techtonik <techtonik at gmail.com> wrote:
> On Sun, Jan 3, 2010 at 10:28 PM, Tarek Ziad? <ziade.tarek at gmail.com> wrote:
>>>
>>> If there any way to get Distribution information given the module name
>>> like 'trac.admin.web_ui' ?in setuptools?
>>>
>>> There is a problem to extract information about exact distribution
>>> name and version when module is already imported in application (Trac
>>> plugins).
>>
>> I am not sure exactly what you are trying to do, but :
>>
>> If your trac plugin was done using entry points (as it says at
>> http://trac.edgewall.org/wiki/TracDev/PluginDevelopment), this means
>> that you can
>> use the iter_entry_points API from pkg_resources: You will get a
>> EntryPoint object that contains a dist attribute, pointing to the
>> distribution infos.
>
> Thanks. Already followed this way. Entrypoints is only one way to
> discover plugins - they will work also if imported directly (there is
> "plugins" folder in every user site setup). When plugin is imported,
> everything we have is a name of its class, its module name and path to
> module file.
>
> I need to figure out if given module belongs to any setuptools
> Distribution to know if it possible to extract any useful information
> from it to display to user in administration panel.

As long as that "plugins" folder is loaded in your WorkingEnv, you
could try to see if the module's __file__ path is under the location
of one distribution listed in the working env.

I can't think of another way. PEP 376 will make this task really
simple in the future, as you will be able to directly ask for the list
of distributions that have installed a given file.


>
> --
> anatoly t.
>



-- 
Tarek Ziad? | http://ziade.org

From lacrima.maxim at gmail.com  Mon Jan  4 22:22:35 2010
From: lacrima.maxim at gmail.com (=?UTF-8?B?0JzQsNC60YHQuNC8IExhY3JpbWE=?=)
Date: Mon, 4 Jan 2010 23:22:35 +0200
Subject: [Distutils] Buildout. Can't start interpreter with -u option.
Message-ID: <5bb76e241001041322j797d7f62jb154fa565c5f70e5@mail.gmail.com>

Hello!

Suppose I have following buildout.cfg:

[buildout]
parts = python
[python]
recipe = zc.recipe.egg
interpreter = python
eggs = mypackage

After running bin/buildout I have python interpreter in bin folder.
My question is why I can't start the python interpreter with -u option, i.e.
'bin/python -u'.
It fails with the following traceback:
Traceback (most recent call last):
  File "/home/maxim/projects/
unikeeper/bin/python", line 11, in <module>
    _options, _args = __import__("getopt").getopt(sys.argv[1:], 'ic:m:')
  File "/usr/lib/python2.6/getopt.py", line 91, in getopt
    opts, args = do_shorts(opts, args[0][1:], shortopts, args[1:])
  File "/usr/lib/python2.6/getopt.py", line 191, in do_shorts
    if short_has_arg(opt, shortopts):
  File "/usr/lib/python2.6/getopt.py", line 207, in short_has_arg
    raise GetoptError('option -%s not recognized' % opt, opt)
getopt.GetoptError: option -u not recognized

Is it a bug?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20100104/4c3778dd/attachment.htm>

From Richard.Plana at enabil.com  Mon Jan  4 22:58:39 2010
From: Richard.Plana at enabil.com (Richard Plana)
Date: Mon, 4 Jan 2010 14:58:39 -0700
Subject: [Distutils] Wrong Filename Extension
Message-ID: <638DC0AAF2CCDD49968CF35FAF41DE5A3873F701E6@HEXMBVS12.hostedmsx.local>

Hi,

While trying to build a python project cx_Freeze-4.1.1 in this case) on Linux, I came up against the following problem:When building one of the packages (cx_Freeze.util) which is a C native extension package, the setup.py script ends up building a file with the name ?util? instead of the expected ?util.so? under the cx_Freeze/ subdirectory.

Any ideas what the problem is? I?m building this on a Fedora 12 x86_64 box which uses python-2.6.2-2.fc12.x86_64.

Note: Manually renaming the file from ?util? to ?util.so? ends up with a working system, but I?m guessing that?s not the ideal scenario.
--

Richard Plana
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20100104/32cdd481/attachment-0001.htm>

From david.lyon at preisshare.net  Tue Jan  5 00:36:56 2010
From: david.lyon at preisshare.net (David Lyon)
Date: Tue, 5 Jan 2010 10:36:56 +1100 (EST)
Subject: [Distutils] test coverage for setuptools
In-Reply-To: <94bdd2611001040606k5a889f53nbf8b8afeaf2900d@mail.gmail.com>
References: <d34314101001030403k299dfd8ble82d5176dd3554f0@mail.gmail.com>
	<94bdd2611001031222v35640d40s52b070bee5940998@mail.gmail.com>
	<d34314101001040553l35899b63k416de30b87820bc5@mail.gmail.com>
	<94bdd2611001040606k5a889f53nbf8b8afeaf2900d@mail.gmail.com>
Message-ID: <1682.218.214.45.58.1262648216.squirrel@syd-srv02.ezyreg.com>


> On Mon, Jan 4, 2010 at 2:53 PM, anatoly techtonik <techtonik at gmail.com>
> wrote:

>>>> Where can I see test coverage results for setuptools package?
>>>> I've got two tracebacks in last week after upgrading and that seems to
>>>> be too much.
>>>> I'd like to see if there are any tests for failing piece to see why
>>>> they might fail before digging further.

We, as in the python community aren't currently doing any
'all-of-python-packages' tests. Like CPAN does, with CPANTS. I think we
tried with
python pants but it got laughed off the planet (kindof sad - as it
was fully in keeping with monty python - chuckle)

Back to serious, in a way, setuptools should be like every other
package on pypi and have code/test analysis run on it.

I've just recently started resurrecting cheesecake putting together a
testbot to do such reports on all the packages on pypi. I'm trying to
correct the output section so that it outputs to a template engine
(cheetah) so the results are less noisy.

The URL is http://bitbucket.org/djlyon/pypi-package-testbot/

In a few weeks, when it is working a bit better I will move it to it's own
domain and publish the reports.

My idea is to build a celery based server farm and use various analysis
tools to measure everything and produce nice reports such as you have
linked to in your email.

It's no trivial task however. There's so many gotcha's in python packaging
that just installing all the packages is a bumpy process.

>> By test coverage results I mean publicly available reports about
>> percentage of code covered by tests that were run by testing
>> buildbots. See examples:
>> http://www.eclipse.org/pde/pde-api-tools/coverage/20091126/eclemma.html
>> http://eigenclass.org/static/rcov-sample-report/
>> http://web.archive.org/web/20070403133248/http://seb.dbzteam.com/pub/urllib2.py.html

We need stuff in python like that.. there's no doubt.

As Tarek says, coverage looks like a good tool. I'd never
seen it till he mentioned it.

If you want to break my bikeshed by joining in you (anybody)
would be more than welcome. I have the time and facilities to
run a testbot but there are specific areas like html reporting
and so forth where I really could use some help. If you need
bribing in beer (well heck - it worked for CPAN), that can
be arranged too. I live in a country with endless beer supplies
and posting to the world is easy..

Regards

David





From david.lyon at preisshare.net  Tue Jan  5 01:33:32 2010
From: david.lyon at preisshare.net (David Lyon)
Date: Tue, 5 Jan 2010 11:33:32 +1100 (EST)
Subject: [Distutils] test coverage for setuptools
In-Reply-To: <d34314101001040553l35899b63k416de30b87820bc5@mail.gmail.com>
References: <d34314101001030403k299dfd8ble82d5176dd3554f0@mail.gmail.com>
	<94bdd2611001031222v35640d40s52b070bee5940998@mail.gmail.com>
	<d34314101001040553l35899b63k416de30b87820bc5@mail.gmail.com>
Message-ID: <1817.218.214.45.58.1262651612.squirrel@syd-srv02.ezyreg.com>


> By test coverage results I mean publicly available reports about
> percentage of code covered by tests that were run by testing
> buildbots. See examples:
> http://www.eclipse.org/pde/pde-api-tools/coverage/20091126/eclemma.html
> http://eigenclass.org/static/rcov-sample-report/
> http://web.archive.org/web/20070403133248/http://seb.dbzteam.com/pub/urllib2.py.html

I can provide you with the following custom report on setuptools:

py_pi_download .........................  50  (downloaded package
setuptools-0.6c11.tar.gz following 1 link from
http://pypi.python.org/packages/source/s/setuptools/setuptools-0.6c11.tar.gz#md5=7df2a529a074f613b509fb44feefe74e)
unpack .................................  25  (package unpacked successfully)
unpack_dir .............................  15  (unpack directory is
setuptools-0.6c11 as expected)
setup.py ...............................  25  (setup.py found)
install ................................  50  (package installed in
production_run_data\tmp_install_setuptools-0.6c11)
generated_files ........................   0  (0 .pyc and 0 .pyo files found)
---------------------------------------------
INSTALLABILITY INDEX (ABSOLUTE) ........ 165
INSTALLABILITY INDEX (RELATIVE) ........ 100  (165 out of a maximum of 165
points is 100%)

required_files .........................  60  (1 files and 1 required
directories found)
docstrings .............................  43  (found 275/652=42.18%
objects with docstrings)
formatted_docstrings ...................   0  (found 49/652=7.52% objects
with formatted docstrings)
---------------------------------------------
DOCUMENTATION INDEX (ABSOLUTE) ......... 103
DOCUMENTATION INDEX (RELATIVE) .........  30  (103 out of a maximum of 350
points is 30%)

unit_tested ............................  30  (has unit tests)
pep8 ...................................  11  (pep8.py check: 10 error
types, 3 warning types)
---------------------------------------------
CODE KWALITEE INDEX (ABSOLUTE) .........  41
CODE KWALITEE INDEX (RELATIVE) .........  65  (41 out of a maximum of 64
points is 65%)


=============================================
OVERALL CHEESECAKE INDEX (ABSOLUTE) .... 309
OVERALL CHEESECAKE INDEX (RELATIVE) ....  53  (309 out of a maximum of 579
points is 53%)



From david.lyon at preisshare.net  Wed Jan  6 03:23:56 2010
From: david.lyon at preisshare.net (David Lyon)
Date: Wed, 6 Jan 2010 13:23:56 +1100 (EST)
Subject: [Distutils] Finishing PEP 345
In-Reply-To: <4B353C81.1080702@v.loewis.de>
References: <94bdd2610912180641i6df1a26co9c3ff34aba034982@mail.gmail.com>
	<4B3224B5.8000503@v.loewis.de>
	<94bdd2610912231045h5df841f5pe90cd46b387b0755@mail.gmail.com>
	<4B3266CF.7030705@v.loewis.de>
	<94bdd2610912231123o6d3236c7j289df78391083ac5@mail.gmail.com>
	<4B3279E9.4010507@v.loewis.de>
	<94bdd2610912231311h44e5563bn98fab09cab3c37f1@mail.gmail.com>
	<4B3324B2.3030708@v.loewis.de>
	<94bdd2610912240132t345b4d8bnc1bc81d5ae82b194@mail.gmail.com>
	<4B334626.6040505@v.loewis.de>
	<94bdd2610912250412m4402a238j741ce6c3bc7ba53d@mail.gmail.com>
	<4B353C81.1080702@v.loewis.de>
Message-ID: <1649.218.214.45.58.1262744636.squirrel@syd-srv02.ezyreg.com>


Tarek, Martin,

Here's my example of a PKG-INFO (Metadata) file.

It is cut down. I'm only using it in-house. However it
demonstrates something important that could be useful
outside, and that is using a source_repository option.

This file has enough information to do a complete
in-house install of the application. Here's the file:

--PKG_INFO-----------------------------------------------------------
  Name: Print Processor
  Platform: Windows
  Description: Captures standard printer output
      and reformats for GDI printers.
  Author: David Lyon
  Source_repository: hg://V:\Software\HG-Repository\PrintProcessor
--------------------------------------------------------------------

Here is how the complete application install takes place:

 * - The 'Name' tag is read. It is used as the 'application'
     name.

 * A directory in "Program Files" is created with that name.
   On Linux, that might be "/usr/local/.." or somewhere else.

   What we end up with is a directory such as :

    '\Program Files\Print Processor'

 * If it was applied to packages, then the directory that
   would be created would be:

    '\PythonX.Y\lib\site-packages\Print Processor'

 * A Mercurial checkout is performed to that directory

 * The directory is checked for a setup.cfg file. If that
   is found, then further infomation such as desktop/program
   file shortcuts can be determined.

 * The PKG_INFO file can be used as some sort of record
   that the application has been installed.

Anyway, that's just how I'm doing it in-house. We have many
tiny applications to control different sorts of unique
machines, interfaces and whatever, and PKG_INFO files
combined with SCM make it really easy to distribute
applications and keep them up to date on the production
machines.

So really, in a way, PKG_INFO files could be the way
to do lot's more. We just need to be able to mention
the name of the source-repository in them and after
that go from there...

David










From jmg3000 at gmail.com  Wed Jan  6 04:29:45 2010
From: jmg3000 at gmail.com (John Gabriele)
Date: Tue, 5 Jan 2010 22:29:45 -0500
Subject: [Distutils] current preferred way to specify dependencies? future?
Message-ID: <65e0bb521001051929m7674b0co25b707120764a440@mail.gmail.com>

Hi,

What is currently the preferred way to specify (in your simple
setup.py file) that your distribution depends upon a couple of other
distributions? (All located at the PyPI)

What is expected to be the standard way to do this in the near future?

Also, is it better to specify that your distribution depends upon some
other *distribution*, or some other *packages/modules*?

Thanks,
---John

From david.lyon at preisshare.net  Wed Jan  6 04:44:06 2010
From: david.lyon at preisshare.net (David Lyon)
Date: Wed, 6 Jan 2010 14:44:06 +1100 (EST)
Subject: [Distutils] current preferred way to specify dependencies?
 future?
In-Reply-To: <65e0bb521001051929m7674b0co25b707120764a440@mail.gmail.com>
References: <65e0bb521001051929m7674b0co25b707120764a440@mail.gmail.com>
Message-ID: <1716.218.214.45.58.1262749446.squirrel@syd-srv02.ezyreg.com>


Hi John,

> What is expected to be the standard way to do this in the near future?

PEP-345 says:

 > Requires-Dist: pywin32 (>1.0); sys.platform == 'win32'
 > Obsoletes-Dist: pywin31; sys.platform == 'win32'
 > Requires-Dist: foo (1,!=1.3); os.machine == 'i386'
 > Requires-Dist: bar; python_version == '2.4' or python_version == '2.5'
 > Requires-External: libxslt; 'linux' in sys.platform

To me that's really confusing. Especially as a windows user.

 > os.machine == 'i386'

Haven't seen a '386 for over ten years.. Intel have standardised
to calling everything 'Pentium' pretty much since at least 2000.

imho 'win32' is a really confusing term. That implies that it won't
work on 64bit. When in fact it mostly will.

> What is currently the preferred way to specify ..

I would much prefer to see:

 > Requires-Dist[windows]: pywin32 (>1.0)

or:

 > Requires-Dist[linux]: pyodbc (>1.0)

or:

 > Requires-Dist[mac]: pyodbc (>1.0)

or:

 > Requires-Dist[mac linux]: pyodbc (>1.0)

as platform markers. It doesn't require a big change to
the PEP. And it is actually simpler to implement I would
expect.

> Also, is it better to specify that your distribution depends upon some
> other *distribution*, or some other *packages/modules*?

I think that means the same thing.

I really hope these guys can make it no more complex than
it needs to be. Then we will all be happy.

David




From martin at v.loewis.de  Wed Jan  6 06:53:19 2010
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Wed, 06 Jan 2010 06:53:19 +0100
Subject: [Distutils] current preferred way to specify dependencies?
	future?
In-Reply-To: <1716.218.214.45.58.1262749446.squirrel@syd-srv02.ezyreg.com>
References: <65e0bb521001051929m7674b0co25b707120764a440@mail.gmail.com>
	<1716.218.214.45.58.1262749446.squirrel@syd-srv02.ezyreg.com>
Message-ID: <4B44254F.4000501@v.loewis.de>

>  > os.machine == 'i386'

It should be platform.machine, not os.machine.

> Haven't seen a '386 for over ten years.. Intel have standardised
> to calling everything 'Pentium' pretty much since at least 2000.

Irrelevant:

Python 2.5.4 (r254:67916, Nov 19 2009, 19:46:21)
[GCC 4.3.4] on linux2
Type "help", "copyright", "credits" or "license" for more information.
py> import platform
py> platform.machine()
'i686'

The platform module has been around in Python for quite some time.
Too bad you haven't noticed it yet.

> imho 'win32' is a really confusing term. That implies that it won't
> work on 64bit. When in fact it mostly will.

No, it implies that the test will be true on all systems where the
platform value in the sys module will be win32. That *also* has
been around for ages (ever since Python started, basically).

> as platform markers. It doesn't require a big change to
> the PEP. And it is actually simpler to implement I would
> expect.

Whereas using the built-in platform identification mechanism
would be extremely difficult?

Regards,
Martin

From jmg3000 at gmail.com  Wed Jan  6 15:35:31 2010
From: jmg3000 at gmail.com (John Gabriele)
Date: Wed, 6 Jan 2010 09:35:31 -0500
Subject: [Distutils] current preferred way to specify dependencies?
	future?
In-Reply-To: <1716.218.214.45.58.1262749446.squirrel@syd-srv02.ezyreg.com>
References: <65e0bb521001051929m7674b0co25b707120764a440@mail.gmail.com>
	<1716.218.214.45.58.1262749446.squirrel@syd-srv02.ezyreg.com>
Message-ID: <65e0bb521001060635o4ad45022ud5a8523e8a3325ec@mail.gmail.com>

On Tue, Jan 5, 2010 at 10:44 PM, David Lyon <david.lyon at preisshare.net> wrote:
>
> Hi John,
>
>> What is expected to be the standard way to do this in the near future?
>
> PEP-345 says:
>
> ?> Requires-Dist: pywin32 (>1.0); sys.platform == 'win32'
> ?> Obsoletes-Dist: pywin31; sys.platform == 'win32'
> ?> Requires-Dist: foo (1,!=1.3); os.machine == 'i386'
> ?> Requires-Dist: bar; python_version == '2.4' or python_version == '2.5'
> ?> Requires-External: libxslt; 'linux' in sys.platform
>
> To me that's really confusing.

I'm a bit confused myself... PEP-345 says it "describes a mechanism
for adding metadata to Python packages", but I think they really mean
"distributions" (the things available at the PyPI).

Also, it looks like pep345 describes what fields can go into a
PKG-INFO file, but not how you get them in there. AFAIK, I'm not
supposed to write my own PKG-INFO file -- setup.py does it for me.
What I'm really asking about here is, what args go in the `setup()`
call in the `setup.py` file?

If my FooBar-0.1.0 distribution depends upon packages and modules in
CoolStuff-2.0.0 and ReallyNeatStuff-1.5.5, what's the current best way
to say so, and what's going to be the standard going forward?

Thanks,
---John

From floris.bruynooghe at gmail.com  Wed Jan  6 17:22:30 2010
From: floris.bruynooghe at gmail.com (Floris Bruynooghe)
Date: Wed, 6 Jan 2010 16:22:30 +0000
Subject: [Distutils] current preferred way to specify dependencies?
 future?
In-Reply-To: <65e0bb521001051929m7674b0co25b707120764a440@mail.gmail.com>
References: <65e0bb521001051929m7674b0co25b707120764a440@mail.gmail.com>
Message-ID: <20100106162230.GA12400@laurie.devork>

Hello John

I'll attempt to actually answer your question instead of just voicing
disagreement with a current proposal about meta-data.

On Tue, Jan 05, 2010 at 10:29:45PM -0500, John Gabriele wrote:
> What is currently the preferred way to specify (in your simple
> setup.py file) that your distribution depends upon a couple of other
> distributions? (All located at the PyPI)

Currently distutils does not support this, all you can do is mention
them in the README.  But setuptools and distribute allow you to
specify dependencies on other distributions.  See
http://peak.telecommunity.com/DevCenter/setuptools#declaring-dependencies
for how to do this.

> What is expected to be the standard way to do this in the near future?

Not sure yet, but PEP 345 is laying the foundations for bringing
something very similar to the current setuptools/distribute
functionality into distutils.  The basics will stay the same: you will
be able to declare dependencies on other distributions (not the actual
modules/packages they provide).


Hope that helps
Floris


-- 
Debian GNU/Linux -- The Power of Freedom
www.debian.org | www.gnu.org | www.kernel.org

From jmg3000 at gmail.com  Wed Jan  6 17:23:17 2010
From: jmg3000 at gmail.com (John Gabriele)
Date: Wed, 6 Jan 2010 11:23:17 -0500
Subject: [Distutils] current preferred way to specify dependencies?
	future?
In-Reply-To: <4B44B542.9010007@dirtcircle.com>
References: <65e0bb521001051929m7674b0co25b707120764a440@mail.gmail.com>
	<1716.218.214.45.58.1262749446.squirrel@syd-srv02.ezyreg.com>
	<65e0bb521001060635o4ad45022ud5a8523e8a3325ec@mail.gmail.com>
	<4B44B542.9010007@dirtcircle.com>
Message-ID: <65e0bb521001060823h34002e6dr9b798863f1849195@mail.gmail.com>

On Wed, Jan 6, 2010 at 11:07 AM, Carl Meyer <carl at dirtcircle.com> wrote:
>
> {snip} Following the principle of least surprise I would assume
> they would be requires_dist, provides_dist, etc, and would take lists of
> strings, in the same format as in the PEP (name followed by version spec
> in parenths).
> {snip}
>
>> If my FooBar-0.1.0 distribution depends upon packages and modules in
>> CoolStuff-2.0.0 and ReallyNeatStuff-1.5.5, what's the current best way
>> to say so, and what's going to be the standard going forward?
>
> The current most-often-used way to say so is to the setuptools-specific
> argument install_requires=['CoolStuff==2.0.0', 'ReallyNeatStuff==1.5.5']
> (though that's being perhaps a bit more precise with the version
> specifiers than you'd really want to be). Obviously that's only
> supported if you use setuptools. The standard going forward will
> hopefully be PEP 345.

Great. Thanks. Then, I'd like to put:

    requires_dist=['CoolStuff>=2.0.0', 'ReallyNeatStuff>=1.5.5'],

into my `setup()` call. Currenlty, I've got this at the top of my `setup.py`:

    from distutils.core import setup

What do I need to change that to, in order for (A) the `requires_dist`
argument to work, and (B) in order to use Distribute rather than
setuptools?

Thanks,
---John

From carl at dirtcircle.com  Wed Jan  6 17:29:06 2010
From: carl at dirtcircle.com (Carl Meyer)
Date: Wed, 06 Jan 2010 11:29:06 -0500
Subject: [Distutils] current preferred way to specify dependencies?
	future?
In-Reply-To: <65e0bb521001060823h34002e6dr9b798863f1849195@mail.gmail.com>
References: <65e0bb521001051929m7674b0co25b707120764a440@mail.gmail.com>	
	<1716.218.214.45.58.1262749446.squirrel@syd-srv02.ezyreg.com>	
	<65e0bb521001060635o4ad45022ud5a8523e8a3325ec@mail.gmail.com>	
	<4B44B542.9010007@dirtcircle.com>
	<65e0bb521001060823h34002e6dr9b798863f1849195@mail.gmail.com>
Message-ID: <4B44BA52.2010306@dirtcircle.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

John Gabriele wrote:
> Great. Thanks. Then, I'd like to put:
> 
>     requires_dist=['CoolStuff>=2.0.0', 'ReallyNeatStuff>=1.5.5'],
> 
> into my `setup()` call. Currenlty, I've got this at the top of my `setup.py`:
> 
>     from distutils.core import setup
> 
> What do I need to change that to, in order for (A) the `requires_dist`
> argument to work, and (B) in order to use Distribute rather than
> setuptools?

Assuming you want this to work _now_, you still need "install_requires",
not "requires_dist".

And you would change "from distutils.core import setup" to "from
setuptools import setup". Since distribute 0.6 is a drop-in replacement
for setuptools, and provides a package named "setuptools", this will use
either setuptools or distribute, whichever happens to be installed.

Carl
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iD8DBQFLRLpS1j/fhc23WEARAou/AKDVyJycdCKtiIDDkOby0HEE7WRxhgCg02F8
cpsqntlhM538vpg9KmRYneQ=
=U7DZ
-----END PGP SIGNATURE-----

From carl at dirtcircle.com  Wed Jan  6 17:07:30 2010
From: carl at dirtcircle.com (Carl Meyer)
Date: Wed, 06 Jan 2010 11:07:30 -0500
Subject: [Distutils] current preferred way to specify
	dependencies?	future?
In-Reply-To: <65e0bb521001060635o4ad45022ud5a8523e8a3325ec@mail.gmail.com>
References: <65e0bb521001051929m7674b0co25b707120764a440@mail.gmail.com>	<1716.218.214.45.58.1262749446.squirrel@syd-srv02.ezyreg.com>
	<65e0bb521001060635o4ad45022ud5a8523e8a3325ec@mail.gmail.com>
Message-ID: <4B44B542.9010007@dirtcircle.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi John,

Isn't distutils-sig fun? Ask a simple question, get a recycled rant that
doesn't answer your question... ;-)

John Gabriele wrote:
[snip]
> I'm a bit confused myself... PEP-345 says it "describes a mechanism
> for adding metadata to Python packages", but I think they really mean
> "distributions" (the things available at the PyPI).

IMO you're right, that word ought to be "distributions", though those
terms often aren't used with as clear a distinction as I'd prefer.

> Also, it looks like pep345 describes what fields can go into a
> PKG-INFO file, but not how you get them in there. AFAIK, I'm not
> supposed to write my own PKG-INFO file -- setup.py does it for me.
> What I'm really asking about here is, what args go in the `setup()`
> call in the `setup.py` file?

I'm not aware that the corresponding setup() args are documented in a
PEP anywhere (hopefully someone will correct me if I'm wrong). Perhaps
they should be. Following the principle of least surprise I would assume
they would be requires_dist, provides_dist, etc, and would take lists of
strings, in the same format as in the PEP (name followed by version spec
in parenths).

The PEP 345 options are named with -Dist suffix precisely because they
name distributions. PEP 314 (which 345 obsoletes) had "Requires",
"Provides" etc, but they named packages/modules. Those never got much
use and are now considered a mistake, which is why they are being
replaced with the *-Dist markers.

> If my FooBar-0.1.0 distribution depends upon packages and modules in
> CoolStuff-2.0.0 and ReallyNeatStuff-1.5.5, what's the current best way
> to say so, and what's going to be the standard going forward?

The current most-often-used way to say so is to the setuptools-specific
argument install_requires=['CoolStuff==2.0.0', 'ReallyNeatStuff==1.5.5']
(though that's being perhaps a bit more precise with the version
specifiers than you'd really want to be). Obviously that's only
supported if you use setuptools. The standard going forward will
hopefully be PEP 345.

Carl
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iD8DBQFLRLVC1j/fhc23WEARAqDsAJ42S+o2kLs21MzJnOYZoRyhpXiA2ACgoAZ/
RgXdl62mgqY8piaDBYK6q8U=
=fpZc
-----END PGP SIGNATURE-----

From sridharr at activestate.com  Wed Jan  6 17:49:37 2010
From: sridharr at activestate.com (Sridhar Ratnakumar)
Date: Wed, 06 Jan 2010 08:49:37 -0800
Subject: [Distutils] current preferred way to specify
	dependencies?	future?
In-Reply-To: <65e0bb521001060823h34002e6dr9b798863f1849195@mail.gmail.com>
References: <65e0bb521001051929m7674b0co25b707120764a440@mail.gmail.com>	<1716.218.214.45.58.1262749446.squirrel@syd-srv02.ezyreg.com>	<65e0bb521001060635o4ad45022ud5a8523e8a3325ec@mail.gmail.com>	<4B44B542.9010007@dirtcircle.com>
	<65e0bb521001060823h34002e6dr9b798863f1849195@mail.gmail.com>
Message-ID: <4B44BF21.3060308@activestate.com>

On 1/6/2010 8:23 AM, John Gabriele wrote:
> On Wed, Jan 6, 2010 at 11:07 AM, Carl Meyer<carl at dirtcircle.com>  wrote:
>> >
>> >  {snip} Following the principle of least surprise I would assume
>> >  they would be requires_dist, provides_dist, etc, and would take lists of
>> >  strings, in the same format as in the PEP (name followed by version spec
>> >  in parenths).
>> >  {snip}
>> >
>>> >>  If my FooBar-0.1.0 distribution depends upon packages and modules in
>>> >>  CoolStuff-2.0.0 and ReallyNeatStuff-1.5.5, what's the current best way
>>> >>  to say so, and what's going to be the standard going forward?
>> >
>> >  The current most-often-used way to say so is to the setuptools-specific
>> >  argument install_requires=['CoolStuff==2.0.0', 'ReallyNeatStuff==1.5.5']
>> >  (though that's being perhaps a bit more precise with the version
>> >  specifiers than you'd really want to be). Obviously that's only
>> >  supported if you use setuptools. The standard going forward will
>> >  hopefully be PEP 345.
> Great. Thanks. Then, I'd like to put:
>
>      requires_dist=['CoolStuff>=2.0.0', 'ReallyNeatStuff>=1.5.5'],
>
> into my `setup()` call. Currenlty, I've got this at the top of my `setup.py`:
>
>      from distutils.core import setup
>
> What do I need to change that to, in order for (A) the `requires_dist`
> argument to work, and (B) in order to use Distribute rather than
> setuptools?

`requires_dist` is not implemented yet, you'll have to use Distribute or 
setuptools. See http://packages.python.org/distribute/using.html

-srid

From ziade.tarek at gmail.com  Wed Jan  6 17:55:56 2010
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Wed, 6 Jan 2010 17:55:56 +0100
Subject: [Distutils] current preferred way to specify dependencies?
	future?
In-Reply-To: <65e0bb521001060635o4ad45022ud5a8523e8a3325ec@mail.gmail.com>
References: <65e0bb521001051929m7674b0co25b707120764a440@mail.gmail.com>
	<1716.218.214.45.58.1262749446.squirrel@syd-srv02.ezyreg.com>
	<65e0bb521001060635o4ad45022ud5a8523e8a3325ec@mail.gmail.com>
Message-ID: <94bdd2611001060855y37812a6es93a8ecdff894da4c@mail.gmail.com>

On Wed, Jan 6, 2010 at 3:35 PM, John Gabriele <jmg3000 at gmail.com> wrote:
> On Tue, Jan 5, 2010 at 10:44 PM, David Lyon <david.lyon at preisshare.net> wrote:
>>
>> Hi John,
>>
>>> What is expected to be the standard way to do this in the near future?
>>
>> PEP-345 says:
>>
>> ?> Requires-Dist: pywin32 (>1.0); sys.platform == 'win32'
>> ?> Obsoletes-Dist: pywin31; sys.platform == 'win32'
>> ?> Requires-Dist: foo (1,!=1.3); os.machine == 'i386'
>> ?> Requires-Dist: bar; python_version == '2.4' or python_version == '2.5'
>> ?> Requires-External: libxslt; 'linux' in sys.platform
>>
>> To me that's really confusing.
>
> I'm a bit confused myself... PEP-345 says it "describes a mechanism
> for adding metadata to Python packages", but I think they really mean
> "distributions" (the things available at the PyPI).

Yes you are right, that was a mistake.  I've just fixed it.

Tarek

-- 
Tarek Ziad? | http://ziade.org

From ziade.tarek at gmail.com  Wed Jan  6 18:13:21 2010
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Wed, 6 Jan 2010 18:13:21 +0100
Subject: [Distutils] [RFC] Python 2.7 Distutils extra features
Message-ID: <94bdd2611001060913n2f984e75t5a0943583fe924d2@mail.gmail.com>

Hello,

Besides the PEP-related features, I would like to add some tiny
features in Distutils for Python 2.7 before the alpha stage is over :

- a test command, that just uses the new unittest discovery to run
unittest-compatible tests.

- a new option for sdist called 'extra_files', that will allow to list
extra files to be included in the distribution. these
  files will not be installed by 'install', just be part of the distribution.

Any comments ?

Regards
Tarek

-- 
Tarek Ziad? | http://ziade.org

From ziade.tarek at gmail.com  Wed Jan  6 18:30:51 2010
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Wed, 6 Jan 2010 18:30:51 +0100
Subject: [Distutils] [RFC] Python 2.7 Distutils extra features
In-Reply-To: <94bdd2611001060913n2f984e75t5a0943583fe924d2@mail.gmail.com>
References: <94bdd2611001060913n2f984e75t5a0943583fe924d2@mail.gmail.com>
Message-ID: <94bdd2611001060930r51478e96p5135b80cfeaf3ff@mail.gmail.com>

On Wed, Jan 6, 2010 at 6:13 PM, Tarek Ziad? <ziade.tarek at gmail.com> wrote:
> Hello,
>
> Besides the PEP-related features, I would like to add some tiny
> features in Distutils for Python 2.7 before the alpha stage is over :
>
> - a test command, that just uses the new unittest discovery to run
> unittest-compatible tests.
>
> - a new option for sdist called 'extra_files', that will allow to list
> extra files to be included in the distribution. these
> ?files will not be installed by 'install', just be part of the distribution.

Ooops forgot the third one, (which might lead to further discussions):

- a very basic pre/post commit hook for the install command.

Tarek

From exarkun at twistedmatrix.com  Wed Jan  6 18:46:48 2010
From: exarkun at twistedmatrix.com (exarkun at twistedmatrix.com)
Date: Wed, 06 Jan 2010 17:46:48 -0000
Subject: [Distutils] [RFC] Python 2.7 Distutils extra features
In-Reply-To: <94bdd2611001060930r51478e96p5135b80cfeaf3ff@mail.gmail.com>
References: <94bdd2611001060913n2f984e75t5a0943583fe924d2@mail.gmail.com>
	<94bdd2611001060930r51478e96p5135b80cfeaf3ff@mail.gmail.com>
Message-ID: <20100106174648.2771.1941061469.divmod.xquotient.85@localhost.localdomain>

On 05:30 pm, ziade.tarek at gmail.com wrote:
>On Wed, Jan 6, 2010 at 6:13 PM, Tarek Ziad? <ziade.tarek at gmail.com> 
>wrote:
>>Hello,
>>
>>Besides the PEP-related features, I would like to add some tiny
>>features in Distutils for Python 2.7 before the alpha stage is over :
>>
>>- a test command, that just uses the new unittest discovery to run
>>unittest-compatible tests.
>>
>>- a new option for sdist called 'extra_files', that will allow to list
>>extra files to be included in the distribution. these
>>?files will not be installed by 'install', just be part of the 
>>distribution.
>
>Ooops forgot the third one, (which might lead to further discussions):
>
>- a very basic pre/post commit hook for the install command.

Being able to run some code after install is done would certainly be 
useful.  A couple things I wonder about...

Can the packages that were just installed be imported in the post hook?

What kind of interaction would this have with the bdist installers? 
It'd be a shame of things like bdist_rpm suffered when packages took 
advantage of these hooks.

Jean-Paul

From ziade.tarek at gmail.com  Wed Jan  6 20:05:05 2010
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Wed, 6 Jan 2010 20:05:05 +0100
Subject: [Distutils] Fwd:  [RFC] Python 2.7 Distutils extra features
In-Reply-To: <94bdd2611001061104q6ec5f5e7vd69db86a174864e1@mail.gmail.com>
References: <94bdd2611001060913n2f984e75t5a0943583fe924d2@mail.gmail.com>
	<94bdd2611001060930r51478e96p5135b80cfeaf3ff@mail.gmail.com>
	<20100106174648.2771.1941061469.divmod.xquotient.85@localhost.localdomain>
	<94bdd2611001061104q6ec5f5e7vd69db86a174864e1@mail.gmail.com>
Message-ID: <94bdd2611001061105t63b20ackbc006d7c6e867788@mail.gmail.com>

oops, forgot to reply-all


---------- Forwarded message ----------
From: Tarek Ziad? <ziade.tarek at gmail.com>
Date: Wed, Jan 6, 2010 at 8:04 PM
Subject: Re: [Distutils] [RFC] Python 2.7 Distutils extra features
To: exarkun at twistedmatrix.com


2010/1/6 ?<exarkun at twistedmatrix.com>:
> On 05:30 pm, ziade.tarek at gmail.com wrote:
>>
>> On Wed, Jan 6, 2010 at 6:13 PM, Tarek Ziad? <ziade.tarek at gmail.com> wrote:
>>>
>>> Hello,
>>>
>>> Besides the PEP-related features, I would like to add some tiny
>>> features in Distutils for Python 2.7 before the alpha stage is over :
>>>
>>> - a test command, that just uses the new unittest discovery to run
>>> unittest-compatible tests.
>>>
>>> - a new option for sdist called 'extra_files', that will allow to list
>>> extra files to be included in the distribution. these
>>> ?files will not be installed by 'install', just be part of the
>>> distribution.
>>
>> Ooops forgot the third one, (which might lead to further discussions):
>>
>> - a very basic pre/post commit hook for the install command.
>
> Being able to run some code after install is done would certainly be useful.
> ?A couple things I wonder about...
>
> Can the packages that were just installed be imported in the post hook?

I guess so.

>
> What kind of interaction would this have with the bdist installers? It'd be
> a shame of things like bdist_rpm suffered when packages took advantage of
> these hooks.

These hooks will be deactivated when any bdist_* command runs install
to create the binary tree.

Now for bdist_rpm own hooks, I guess the best way would be to make
install consumes the same two options
than bdist_rpm (pre-install, post-install) so a project will be able
to define a hook that is used by RPM or python setup.py install




> Jean-Paul
>



--
Tarek Ziad? | http://ziade.org



-- 
Tarek Ziad? | http://ziade.org

From jmg3000 at gmail.com  Wed Jan  6 20:23:31 2010
From: jmg3000 at gmail.com (John Gabriele)
Date: Wed, 6 Jan 2010 14:23:31 -0500
Subject: [Distutils] [RFC] Python 2.7 Distutils extra features
In-Reply-To: <94bdd2611001060913n2f984e75t5a0943583fe924d2@mail.gmail.com>
References: <94bdd2611001060913n2f984e75t5a0943583fe924d2@mail.gmail.com>
Message-ID: <65e0bb521001061123l266dd47le06dc7a03bffc7f1@mail.gmail.com>

On Wed, Jan 6, 2010 at 12:13 PM, Tarek Ziad? <ziade.tarek at gmail.com> wrote:
>
> - a new option for sdist called 'extra_files', that will allow to list
> extra files to be included in the distribution. these
> ?files will not be installed by 'install', just be part of the distribution.
>
> Any comments ?

Would this replace the need for MANIFEST.in?

If not, what would MANIFEST.in still be used for?

From ziade.tarek at gmail.com  Wed Jan  6 20:34:01 2010
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Wed, 6 Jan 2010 20:34:01 +0100
Subject: [Distutils] [RFC] Python 2.7 Distutils extra features
In-Reply-To: <65e0bb521001061123l266dd47le06dc7a03bffc7f1@mail.gmail.com>
References: <94bdd2611001060913n2f984e75t5a0943583fe924d2@mail.gmail.com>
	<65e0bb521001061123l266dd47le06dc7a03bffc7f1@mail.gmail.com>
Message-ID: <94bdd2611001061134u29501432ra7680fbba001df40@mail.gmail.com>

On Wed, Jan 6, 2010 at 8:23 PM, John Gabriele <jmg3000 at gmail.com> wrote:
> On Wed, Jan 6, 2010 at 12:13 PM, Tarek Ziad? <ziade.tarek at gmail.com> wrote:
>>
>> - a new option for sdist called 'extra_files', that will allow to list
>> extra files to be included in the distribution. these
>> ?files will not be installed by 'install', just be part of the distribution.
>>
>> Any comments ?
>
> Would this replace the need for MANIFEST.in?
>
> If not, what would MANIFEST.in still be used for?

No quite, because the MANIFEST.in template allows you to exclude some
files, and to do recursive operations.
We could add an "exclude_files" option to cover exclusion, and have a
glob-style pattern for both.

I am not sure about the recursion yet though.


-- 
Tarek Ziad? | http://ziade.org

From tseaver at palladion.com  Wed Jan  6 23:21:05 2010
From: tseaver at palladion.com (Tres Seaver)
Date: Wed, 06 Jan 2010 17:21:05 -0500
Subject: [Distutils] current preferred way to specify dependencies?
	future?
In-Reply-To: <65e0bb521001060635o4ad45022ud5a8523e8a3325ec@mail.gmail.com>
References: <65e0bb521001051929m7674b0co25b707120764a440@mail.gmail.com>	<1716.218.214.45.58.1262749446.squirrel@syd-srv02.ezyreg.com>
	<65e0bb521001060635o4ad45022ud5a8523e8a3325ec@mail.gmail.com>
Message-ID: <hi32ch$jnd$1@ger.gmane.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

John Gabriele wrote:
> On Tue, Jan 5, 2010 at 10:44 PM, David Lyon <david.lyon at preisshare.net> wrote:
>> Hi John,
>>
>>> What is expected to be the standard way to do this in the near future?
>> PEP-345 says:
>>
>>  > Requires-Dist: pywin32 (>1.0); sys.platform == 'win32'
>>  > Obsoletes-Dist: pywin31; sys.platform == 'win32'
>>  > Requires-Dist: foo (1,!=1.3); os.machine == 'i386'
>>  > Requires-Dist: bar; python_version == '2.4' or python_version == '2.5'
>>  > Requires-External: libxslt; 'linux' in sys.platform
>>
>> To me that's really confusing.
> 
> I'm a bit confused myself... PEP-345 says it "describes a mechanism
> for adding metadata to Python packages", but I think they really mean
> "distributions" (the things available at the PyPI).
> 
> Also, it looks like pep345 describes what fields can go into a
> PKG-INFO file, but not how you get them in there. AFAIK, I'm not
> supposed to write my own PKG-INFO file -- setup.py does it for me.
> What I'm really asking about here is, what args go in the `setup()`
> call in the `setup.py` file?

Out of scope for the PEP, which only specifies the format of the
PKG-INFO file.  Once the pep is accepted, distutils will add arguments
to setup() to allow setting the new fields.

> If my FooBar-0.1.0 distribution depends upon packages and modules in
> CoolStuff-2.0.0 and ReallyNeatStuff-1.5.5, what's the current best way
> to say so, and what's going to be the standard going forward?

Currently, use setuptools, and pass your dependencies to setup() via
'install_requires'::

  from setuptools import setup

  setup(name='FooBar',
        version='0.1.0',
        ...
        install_requires=[
          'CoolStuff>=2.0.0',
          'ReallyNeatStuff>=1.5.5',
        ],
        ...
       )

Eventually (Python 2.7 or later, we hope), you will be able to pass
similar keyword arguments directly to the distutils, or (even better)
spell them in some declarative file which the distutils reads.


Tres.
- --
===================================================================
Tres Seaver          +1 540-429-0999          tseaver at palladion.com
Palladion Software   "Excellence by Design"    http://palladion.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAktFDMwACgkQ+gerLs4ltQ7ozACeNQKPVPDQp0lr+TetT36LkNIv
kQYAn0cNZOlkfAC68nyx50ZH8+/CCOGR
=xMD6
-----END PGP SIGNATURE-----


From barry at python.org  Thu Jan  7 00:17:18 2010
From: barry at python.org (Barry Warsaw)
Date: Wed, 6 Jan 2010 18:17:18 -0500
Subject: [Distutils] distribute 0.6.10 and convert_2to3_doctests
Message-ID: <20100106181718.2a506964@freewill>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

I have a Python package called 'munepy' <https://launchpad.net/munepy> which
provides yet another flavor of enums.  I'm working on the code for various
reasons and I thought I'd take the opportunity to learn how to support both
Python 2 and 3 from the same code base.

I've updated the code so that it supports Python 2.6 at a minimum, and made it
'python -3' clean.  I've switched it from using setuptools to using
distribute.  I was looking at this page:

    http://packages.python.org/distribute/python3.html

and it seems very cool that distribute can help make my life easier by
allowing me to support both Python 2 and 3 from the same code base.  I set
use_2to3=True in my setup.py and indeed

    % python3 setup.py test

(On Ubuntu 9.10) runs 2to3 over my .py files.  However, my doctests are in
separate .txt files and I cannot seem to get the right incantation for
convert_2to3_doctests.

In the root of my source directory, my doctest lives at
munepy/docs/README.txt, so I put this in my setup.py:

    ...
    use_2to3 = True,
    convert_2to3_doctests = [
        'munepy/docs/README.txt',
        ],
    ...

but I never see that the README.txt is ever 'fixed'.  Indeed, the test fails
because of a syntax error when the doctest tries to print something using
Python 2 syntax.  I'm clearly not using this setup argument correctly, but I
can't tell where I'm going wrong.

How do you use convert_2to3_doctests?

TIA,
- -Barry
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iQIcBAEBCAAGBQJLRRn+AAoJEBJutWOnSwa/U78P/06neAOc4cbeaKty7OX1AvUo
9QKwNrmH5U/spbvvThPKCl+XXPDJdD4K40zCSaq98vGXdjxIgBapCvQi3/lUBtKM
M5CBVJvsbJnaeAZUjUS2EZ+CLXkMAmWA/8znmo3xsGJ+8+F77Wb9iTwobQpQqmWJ
z43BLaiT62fzWqC4vsBjG6JMF0VZZZ51IRrzD48lasYItHa4cUQa/brC8jwGUhE4
060zo+cof5UvbMRNP0OU69p0M5PztOtszLKHaOhD8EsAF8r1PWtOT2oGpij8jLst
GBp82J+JOlgWiEFSmVLaSOl/0D0193ut+PtHLCLDOJ9sVXgIKv4RvWMip1/0W1bB
btneAIUJ/CFxCJuBcadkGtwS9geuaM+ma2rlYOpwTBncBEZx9XVPOxnEuCyUSrSo
03QXZ6xxOKf1Xepg3AjDD2KSxrAZHoG4aLVGdxqFyAebpC9hiKYRrLswe5mg/ycj
eo5lpKjGplL5Md0O9ZgJmqk0UH4CVZy7Imrv8BMQcMCZLkbs42FnMXtXVWEVQ9qm
iA3T54Yi5dOZB56JjnkftyS15in8W5OiV1X78WtblQ7/f5oR1UXq72mZU3k+3nrX
kxWfzsHAo1v34+WHUagmYZqLYtm/zFT+zHwoyzzMcWpJSTH8WIOud9IuSkg5gA3S
B2iMITFAZnXKzB644gIP
=GqOL
-----END PGP SIGNATURE-----

From david.lyon at preisshare.net  Thu Jan  7 09:39:57 2010
From: david.lyon at preisshare.net (David Lyon)
Date: Thu, 7 Jan 2010 19:39:57 +1100 (EST)
Subject: [Distutils] current preferred way to specify dependencies?
 future?
In-Reply-To: <4B44254F.4000501@v.loewis.de>
References: <65e0bb521001051929m7674b0co25b707120764a440@mail.gmail.com>
	<1716.218.214.45.58.1262749446.squirrel@syd-srv02.ezyreg.com>
	<4B44254F.4000501@v.loewis.de>
Message-ID: <3473.165.228.171.167.1262853597.squirrel@syd-srv02.ezyreg.com>

>>  > os.machine == 'i386'
>
> It should be platform.machine, not os.machine.
>
>> Haven't seen a '386 for over ten years.. Intel have standardised
>> to calling everything 'Pentium' pretty much since at least 2000.
>
> Irrelevant:

I don't see how it is irrelevent that the constants don't
map to any 'real' machines on the market.

> The platform module has been around in Python for quite some time.
> Too bad you haven't noticed it yet.

Actually I do know about it. But I was only commenting about the PEP as it
stands.

>> imho 'win32' is a really confusing term. That implies that it won't
>> work on 64bit. When in fact it mostly will.
>
> No, it implies that the test will be true on all systems where the
> platform value in the sys module will be win32. That *also* has
> been around for ages (ever since Python started, basically).

I know that you know that. But people without the programming legacy that
you do can't be expected to know that.

> Whereas using the built-in platform identification mechanism
> would be extremely difficult?

The problem is that you can't buy any machine from the shop called
'darwin'. You can't buy any notebook/desktop new machine
with an i386 processor in it.

Any new kid can't buy a darwin or an i386 notebook.

We don't use "steam-train" to denote an "ICE" train. It is
just not right. Sorry.

The module is flawed and doesn't reflect the real world.

Why build a new PEP upon a module with errors? It doesn't make sense.

But this is just the start. I'll outline more problems to come.

Starting new PEPs based on erroneous system APIs? Sorry
I think that is lower than your normallly incredibly
high standard of workmanship.

David




From regebro at gmail.com  Thu Jan  7 12:09:05 2010
From: regebro at gmail.com (Lennart Regebro)
Date: Thu, 7 Jan 2010 12:09:05 +0100
Subject: [Distutils] distribute 0.6.10 and convert_2to3_doctests
In-Reply-To: <20100106181718.2a506964@freewill>
References: <20100106181718.2a506964@freewill>
Message-ID: <319e029f1001070309kba96eb8ha8031d2dfd285844@mail.gmail.com>

On Thu, Jan 7, 2010 at 00:17, Barry Warsaw <barry at python.org> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> I have a Python package called 'munepy' <https://launchpad.net/munepy> which
> provides yet another flavor of enums. ?I'm working on the code for various
> reasons and I thought I'd take the opportunity to learn how to support both
> Python 2 and 3 from the same code base.
>
> I've updated the code so that it supports Python 2.6 at a minimum, and made it
> 'python -3' clean. ?I've switched it from using setuptools to using
> distribute. ?I was looking at this page:
>
> ? ?http://packages.python.org/distribute/python3.html
>
> and it seems very cool that distribute can help make my life easier by
> allowing me to support both Python 2 and 3 from the same code base. ?I set
> use_2to3=True in my setup.py and indeed
>
> ? ?% python3 setup.py test
>
> (On Ubuntu 9.10) runs 2to3 over my .py files. ?However, my doctests are in
> separate .txt files and I cannot seem to get the right incantation for
> convert_2to3_doctests.
>
> In the root of my source directory, my doctest lives at
> munepy/docs/README.txt, so I put this in my setup.py:
>
> ? ?...
> ? ?use_2to3 = True,
> ? ?convert_2to3_doctests = [
> ? ? ? ?'munepy/docs/README.txt',
> ? ? ? ?],
> ? ?...
>
> but I never see that the README.txt is ever 'fixed'. ?Indeed, the test fails
> because of a syntax error when the doctest tries to print something using
> Python 2 syntax. ?I'm clearly not using this setup argument correctly, but I
> can't tell where I'm going wrong.
>
> How do you use convert_2to3_doctests?

Exactly like this. Note, however, that Distribute doesn't know that
the file isn't already converted. It will look at the timestamps of
the files, notice it hasn't changed, and do nothing. So you need to
delete the target file in build/ and rerun the tests to have it run
the conversion.
-- 
Lennart Regebro: Python, Zope, Plone, Grok
http://regebro.wordpress.com/
+33 661 58 14 64

From barry at python.org  Thu Jan  7 12:31:30 2010
From: barry at python.org (Barry Warsaw)
Date: Thu, 7 Jan 2010 06:31:30 -0500
Subject: [Distutils] distribute 0.6.10 and convert_2to3_doctests
In-Reply-To: <319e029f1001070309kba96eb8ha8031d2dfd285844@mail.gmail.com>
References: <20100106181718.2a506964@freewill>
	<319e029f1001070309kba96eb8ha8031d2dfd285844@mail.gmail.com>
Message-ID: <F059AED4-FD82-44D6-A128-5D80DE2A335C@python.org>

On Jan 7, 2010, at 6:09 AM, Lennart Regebro wrote:
>> 
>>    ...
>>    use_2to3 = True,
>>    convert_2to3_doctests = [
>>        'munepy/docs/README.txt',
>>        ],
>>    ...
>> 
>> but I never see that the README.txt is ever 'fixed'.  Indeed, the test fails
>> because of a syntax error when the doctest tries to print something using
>> Python 2 syntax.  I'm clearly not using this setup argument correctly, but I
>> can't tell where I'm going wrong.
>> 
>> How do you use convert_2to3_doctests?
> 
> Exactly like this. Note, however, that Distribute doesn't know that
> the file isn't already converted. It will look at the timestamps of
> the files, notice it hasn't changed, and do nothing. So you need to
> delete the target file in build/ and rerun the tests to have it run
> the conversion.

Hi Lennart, thanks for the response.  However, I don't think this is quite it.  I read this in the docs and deleted the entire build directory.  Then when I re-run the tests I can see that the .py files get "fixed" but it never tries to fix the README.txt.

-Barry


From bradallen137 at gmail.com  Thu Jan  7 12:40:44 2010
From: bradallen137 at gmail.com (Brad Allen)
Date: Thu, 7 Jan 2010 05:40:44 -0600
Subject: [Distutils] packaging terminology confusion
Message-ID: <4957f1ef1001070340y94da3cbgbc6dfe6c05028f3f@mail.gmail.com>

This quote is taken from the distutils thread "current preferred way
to specify dependencies? future?",

On Wed, Jan 6, 2010 at 10:55 AM, Tarek Ziad? <ziade.tarek at gmail.com> wrote:
> On Wed, Jan 6, 2010 at 3:35 PM, John Gabriele <jmg3000 at gmail.com> wrote:
>> I'm a bit confused myself... PEP-345 says it "describes a mechanism
>> for adding metadata to Python packages", but I think they really mean
>> "distributions" (the things available at the PyPI).
>
> Yes you are right, that was a mistake. ?I've just fixed it.

Sorry, but I'm baffled. Are we really now using the word
'distribution' for those 'things available at the PyPI'?

The text inside PEP-345 uses the word 'distutils project' a lot as the
name for this concept.

It's very common to see the word 'package' used to refer to these
'distutils projects'; but in the Python documentation we also use the
word 'package' to refer to any directory having an __init__.py.  Can
the word 'package' be used for both concepts? Maybe a qualifier would
help, like module-package and setup-package.

Normally the word 'distribution' is reserved for what lands in the
'dist' directory, such as a tarball or an egg...right?

From eric at trueblade.com  Thu Jan  7 12:48:08 2010
From: eric at trueblade.com (Eric Smith)
Date: Thu, 07 Jan 2010 06:48:08 -0500
Subject: [Distutils] packaging terminology confusion
In-Reply-To: <4957f1ef1001070340y94da3cbgbc6dfe6c05028f3f@mail.gmail.com>
References: <4957f1ef1001070340y94da3cbgbc6dfe6c05028f3f@mail.gmail.com>
Message-ID: <4B45C9F8.6070608@trueblade.com>

Brad Allen wrote:
> This quote is taken from the distutils thread "current preferred way
> to specify dependencies? future?",
> 
> On Wed, Jan 6, 2010 at 10:55 AM, Tarek Ziad? <ziade.tarek at gmail.com> wrote:
>> On Wed, Jan 6, 2010 at 3:35 PM, John Gabriele <jmg3000 at gmail.com> wrote:
>>> I'm a bit confused myself... PEP-345 says it "describes a mechanism
>>> for adding metadata to Python packages", but I think they really mean
>>> "distributions" (the things available at the PyPI).
>> Yes you are right, that was a mistake.  I've just fixed it.
> 
> Sorry, but I'm baffled. Are we really now using the word
> 'distribution' for those 'things available at the PyPI'?
> 
> The text inside PEP-345 uses the word 'distutils project' a lot as the
> name for this concept.
> 
> It's very common to see the word 'package' used to refer to these
> 'distutils projects'; but in the Python documentation we also use the
> word 'package' to refer to any directory having an __init__.py.  Can
> the word 'package' be used for both concepts? Maybe a qualifier would
> help, like module-package and setup-package.
> 
> Normally the word 'distribution' is reserved for what lands in the
> 'dist' directory, such as a tarball or an egg...right?

We should use the terminology as defined in 
http://docs.python.org/distutils/introduction.html#distutils-specific-terminology

So technically it's a "module distribution" we're talking about.

From ziade.tarek at gmail.com  Thu Jan  7 13:03:26 2010
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Thu, 7 Jan 2010 13:03:26 +0100
Subject: [Distutils] packaging terminology confusion
In-Reply-To: <4B45C9F8.6070608@trueblade.com>
References: <4957f1ef1001070340y94da3cbgbc6dfe6c05028f3f@mail.gmail.com>
	<4B45C9F8.6070608@trueblade.com>
Message-ID: <94bdd2611001070403u2834bdc3o87eab30dc5c8b7e4@mail.gmail.com>

On Thu, Jan 7, 2010 at 12:48 PM, Eric Smith <eric at trueblade.com> wrote:
[..]
>> Normally the word 'distribution' is reserved for what lands in the
>> 'dist' directory, such as a tarball or an egg...right?

Right.

>
> We should use the terminology as defined in
> http://docs.python.org/distutils/introduction.html#distutils-specific-terminology
>
> So technically it's a "module distribution" we're talking about.

Well, I wonder if we shouln't use the term "distribution" instead
here. the "module" word is quite fuzzy to describe a distribution that
might contain modules, data files, and/or packages. It doesn't bring
any useful information to the terms here.

Tarek

From eric at trueblade.com  Thu Jan  7 13:24:55 2010
From: eric at trueblade.com (Eric Smith)
Date: Thu, 07 Jan 2010 07:24:55 -0500
Subject: [Distutils] packaging terminology confusion
In-Reply-To: <94bdd2611001070403u2834bdc3o87eab30dc5c8b7e4@mail.gmail.com>
References: <4957f1ef1001070340y94da3cbgbc6dfe6c05028f3f@mail.gmail.com>	
	<4B45C9F8.6070608@trueblade.com>
	<94bdd2611001070403u2834bdc3o87eab30dc5c8b7e4@mail.gmail.com>
Message-ID: <4B45D297.1010003@trueblade.com>

Tarek Ziad? wrote:
> On Thu, Jan 7, 2010 at 12:48 PM, Eric Smith <eric at trueblade.com> wrote:
> [..]
>>> Normally the word 'distribution' is reserved for what lands in the
>>> 'dist' directory, such as a tarball or an egg...right?
> 
> Right.
> 
>> We should use the terminology as defined in
>> http://docs.python.org/distutils/introduction.html#distutils-specific-terminology
>>
>> So technically it's a "module distribution" we're talking about.
> 
> Well, I wonder if we shouln't use the term "distribution" instead
> here. the "module" word is quite fuzzy to describe a distribution that
> might contain modules, data files, and/or packages. It doesn't bring
> any useful information to the terms here.

You're right: the word "module" here is confusing, since it has another 
meaning (and is even mentioned in the previous section). But "module 
definition" is indeed the correct term. Maybe we should mention that 
where we use "distribution", the full term is "module definition" as 
defined in that section. Calling it "module definition" throughout the 
PEP would be horrible.

From floris.bruynooghe at gmail.com  Thu Jan  7 13:44:18 2010
From: floris.bruynooghe at gmail.com (Floris Bruynooghe)
Date: Thu, 7 Jan 2010 12:44:18 +0000
Subject: [Distutils] [RFC] Python 2.7 Distutils extra features
In-Reply-To: <94bdd2611001060913n2f984e75t5a0943583fe924d2@mail.gmail.com>
References: <94bdd2611001060913n2f984e75t5a0943583fe924d2@mail.gmail.com>
Message-ID: <20100107124418.GA17103@laurie.devork>

Hi Tarek

On Wed, Jan 06, 2010 at 06:13:21PM +0100, Tarek Ziad? wrote:
> Besides the PEP-related features, I would like to add some tiny
> features in Distutils for Python 2.7 before the alpha stage is over :
> 
> - a test command, that just uses the new unittest discovery to run
> unittest-compatible tests.

Will it be easy to change this to use py.test or nose?  Or will that
just be the normal command overriding mechanism?


Regards
Floris

-- 
Debian GNU/Linux -- The Power of Freedom
www.debian.org | www.gnu.org | www.kernel.org

From regebro at gmail.com  Thu Jan  7 14:34:21 2010
From: regebro at gmail.com (Lennart Regebro)
Date: Thu, 7 Jan 2010 14:34:21 +0100
Subject: [Distutils] distribute 0.6.10 and convert_2to3_doctests
In-Reply-To: <F059AED4-FD82-44D6-A128-5D80DE2A335C@python.org>
References: <20100106181718.2a506964@freewill>
	<319e029f1001070309kba96eb8ha8031d2dfd285844@mail.gmail.com>
	<F059AED4-FD82-44D6-A128-5D80DE2A335C@python.org>
Message-ID: <319e029f1001070534j44556099x89d5029aac9d67e9@mail.gmail.com>

On Thu, Jan 7, 2010 at 12:31, Barry Warsaw <barry at python.org> wrote:
> Hi Lennart, thanks for the response. ?However, I don't think this is quite it. ?I read this in the docs and deleted the entire build directory. ?Then when I re-run the tests I can see that the .py files get "fixed" but it never tries to fix the README.txt.

I just checked out munepy, and tried it, and with me the problem is
that it doesn't even copy it. That's because Distribute sees any
non-python file as "Package data", which means you have to set
include_package_data = True in setup().

There is a bug here, or several. I suspect we should try to copy
doctest files in this case, even if you don't have
include_package_data, and also Distribute should complain if the
specified doctest file doesn't exist or isn't being copied.

But in any case, once I add "include_package_data = True" it works for
me, the file does get copied and converted.

The next problem is that the tests seem to be run on the original, and
not on the build-copy. And why that is, I don't know, and I have to
debug that, which I can't do right now. I'll try tonight or tomorrow.
It's most likely a bug in Distribute.

-- 
Lennart Regebro: http://regebro.wordpress.com/
Python 3 Porting: http://python-incompatibility.googlecode.com/
+33 661 58 14 64

From jmg3000 at gmail.com  Thu Jan  7 15:52:53 2010
From: jmg3000 at gmail.com (John Gabriele)
Date: Thu, 7 Jan 2010 09:52:53 -0500
Subject: [Distutils] packaging terminology confusion
In-Reply-To: <94bdd2611001070403u2834bdc3o87eab30dc5c8b7e4@mail.gmail.com>
References: <4957f1ef1001070340y94da3cbgbc6dfe6c05028f3f@mail.gmail.com>
	<4B45C9F8.6070608@trueblade.com>
	<94bdd2611001070403u2834bdc3o87eab30dc5c8b7e4@mail.gmail.com>
Message-ID: <65e0bb521001070652k6925da3ak3a89ca484234f6b5@mail.gmail.com>

On Thu, Jan 7, 2010 at 7:03 AM, Tarek Ziad? <ziade.tarek at gmail.com> wrote:
> On Thu, Jan 7, 2010 at 12:48 PM, Eric Smith <eric at trueblade.com> wrote:
> [..]
>>
>> We should use the terminology as defined in
>> http://docs.python.org/distutils/introduction.html#distutils-specific-terminology
>>
>> So technically it's a "module distribution" we're talking about.
>
> Well, I wonder if we shouln't use the term "distribution" instead
> here. the "module" word is quite fuzzy to describe a distribution that
> might contain modules, data files, and/or packages.

I agree, since you can make a distribution with nothing in it but
scripts (no modules or packages). Nice way to distribute "python
programs" too, IMO.

Incidentally, the Perl folk technically refer to the things they
upload to the CPAN as "distributions" as well. Though, they often call
them "modules" in casual conversation/writing ... possibly because
it's 2 syllables shorter and/or easier to type. :)

The only inconsistency, I think, is that operating systems like Debian
refer to their software distributions as "packages" (as in, a packaged
up piece of software that you can download and install). "Packages" is
a great name for them -- too bad it's already being used in Python.

---John

From ziade.tarek at gmail.com  Thu Jan  7 15:56:22 2010
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Thu, 7 Jan 2010 15:56:22 +0100
Subject: [Distutils] packaging terminology confusion
In-Reply-To: <65e0bb521001070652k6925da3ak3a89ca484234f6b5@mail.gmail.com>
References: <4957f1ef1001070340y94da3cbgbc6dfe6c05028f3f@mail.gmail.com>
	<4B45C9F8.6070608@trueblade.com>
	<94bdd2611001070403u2834bdc3o87eab30dc5c8b7e4@mail.gmail.com>
	<65e0bb521001070652k6925da3ak3a89ca484234f6b5@mail.gmail.com>
Message-ID: <94bdd2611001070656k3268b2b9n8f5bc2fdab747f3d@mail.gmail.com>

On Thu, Jan 7, 2010 at 3:52 PM, John Gabriele <jmg3000 at gmail.com> wrote:
> The only inconsistency, I think, is that operating systems like Debian
> refer to their software distributions as "packages" (as in, a packaged
> up piece of software that you can download and install). "Packages" is
> a great name for them -- too bad it's already being used in Python.

I believe that's basically where the confusion comes from.

From jmg3000 at gmail.com  Thu Jan  7 16:12:01 2010
From: jmg3000 at gmail.com (John Gabriele)
Date: Thu, 7 Jan 2010 10:12:01 -0500
Subject: [Distutils] packaging terminology confusion
In-Reply-To: <94bdd2611001070656k3268b2b9n8f5bc2fdab747f3d@mail.gmail.com>
References: <4957f1ef1001070340y94da3cbgbc6dfe6c05028f3f@mail.gmail.com>
	<4B45C9F8.6070608@trueblade.com>
	<94bdd2611001070403u2834bdc3o87eab30dc5c8b7e4@mail.gmail.com>
	<65e0bb521001070652k6925da3ak3a89ca484234f6b5@mail.gmail.com>
	<94bdd2611001070656k3268b2b9n8f5bc2fdab747f3d@mail.gmail.com>
Message-ID: <65e0bb521001070712o28cd5d92mc46c4fd4fcb4fca@mail.gmail.com>

On Thu, Jan 7, 2010 at 9:56 AM, Tarek Ziad? <ziade.tarek at gmail.com> wrote:
> On Thu, Jan 7, 2010 at 3:52 PM, John Gabriele <jmg3000 at gmail.com> wrote:
>> The only inconsistency, I think, is that operating systems like Debian
>> refer to their software distributions as "packages" (as in, a packaged
>> up piece of software that you can download and install). "Packages" is
>> a great name for them -- too bad it's already being used in Python.
>
> I believe that's basically where the confusion comes from.

Whoops. Just noticed that the front page of the PyPI says:

> "There are currently 8614 packages here."

(is that 8614 packages or 8614 distributions?)

and,

> "To submit a package use "python setup.py upload" and to use a package from this index either "pip install package" or download, unpack and "python setup.py install" it."

and

> "# Browse the tree of packages
# Submit package information"

---John

From ziade.tarek at gmail.com  Thu Jan  7 16:25:52 2010
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Thu, 7 Jan 2010 16:25:52 +0100
Subject: [Distutils] [RFC] Python 2.7 Distutils extra features
In-Reply-To: <20100107124418.GA17103@laurie.devork>
References: <94bdd2611001060913n2f984e75t5a0943583fe924d2@mail.gmail.com>
	<20100107124418.GA17103@laurie.devork>
Message-ID: <94bdd2611001070725w7eccb2b4s3481c67323f3f4d5@mail.gmail.com>

On Thu, Jan 7, 2010 at 1:44 PM, Floris Bruynooghe
<floris.bruynooghe at gmail.com> wrote:
> Hi Tarek
>
> On Wed, Jan 06, 2010 at 06:13:21PM +0100, Tarek Ziad? wrote:
>> Besides the PEP-related features, I would like to add some tiny
>> features in Distutils for Python 2.7 before the alpha stage is over :
>>
>> - a test command, that just uses the new unittest discovery to run
>> unittest-compatible tests.
>
> Will it be easy to change this to use py.test or nose? ?Or will that
> just be the normal command overriding mechanism?

Are you referring to Setuptools' test_suite option ?

Distutils test command could have a similar mechanism, but without the
auto-installation machinery that comes with Setuptools' one, or the
entry points. e.g. running test will not install a third-party
package, and will not do a plugin discovery. So one may pass the name
of a module or method, like "nose.collector" for delegating the test
collecting.

But is there a real use case for that ? I mean, you use Nose, can't
you just run nosetests in the root ?

Or is this for avoing a PATH manipulation on win32 systems ? where
sys.prefix+/Scripts is not in PATH.

Tarek

From barry at python.org  Thu Jan  7 16:36:50 2010
From: barry at python.org (Barry Warsaw)
Date: Thu, 7 Jan 2010 10:36:50 -0500
Subject: [Distutils] distribute 0.6.10 and convert_2to3_doctests
In-Reply-To: <319e029f1001070534j44556099x89d5029aac9d67e9@mail.gmail.com>
References: <20100106181718.2a506964@freewill>
	<319e029f1001070309kba96eb8ha8031d2dfd285844@mail.gmail.com>
	<F059AED4-FD82-44D6-A128-5D80DE2A335C@python.org>
	<319e029f1001070534j44556099x89d5029aac9d67e9@mail.gmail.com>
Message-ID: <20100107103650.19485f0e@limelight.wooz.org>

On Jan 07, 2010, at 02:34 PM, Lennart Regebro wrote:

>I just checked out munepy, and tried it, and with me the problem is
>that it doesn't even copy it. That's because Distribute sees any
>non-python file as "Package data", which means you have to set
>include_package_data = True in setup().

Ah yes, of course.  Thanks, that's definitely a bug in my setup.py.  I've
fixed this and pushed up the latest revisions.  I will upload the package to
pypi soon.

>There is a bug here, or several. I suspect we should try to copy
>doctest files in this case, even if you don't have
>include_package_data, and also Distribute should complain if the
>specified doctest file doesn't exist or isn't being copied.

Either way seems fine.  It would be nice to have more automatic support of
doctests in general, but I'm also okay with Distribute just complaining and
making me fix my setup.py.

>But in any case, once I add "include_package_data = True" it works for
>me, the file does get copied and converted.
>
>The next problem is that the tests seem to be run on the original, and
>not on the build-copy. And why that is, I don't know, and I have to
>debug that, which I can't do right now. I'll try tonight or tomorrow.
>It's most likely a bug in Distribute.

Thanks.  I wonder if my test_documentation.py is doing evil things that
confuse Distribute?

I really think getting this right will provide a very powerful incentive to
Python package authors, both to switch to Distribute and to support Python 3.
I'm very excited to see this functionality.

-Barry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20100107/535023a2/attachment-0001.pgp>

From bradallen137 at gmail.com  Thu Jan  7 17:29:45 2010
From: bradallen137 at gmail.com (Brad Allen)
Date: Thu, 7 Jan 2010 10:29:45 -0600
Subject: [Distutils] packaging terminology confusion
In-Reply-To: <65e0bb521001070712o28cd5d92mc46c4fd4fcb4fca@mail.gmail.com>
References: <4957f1ef1001070340y94da3cbgbc6dfe6c05028f3f@mail.gmail.com>
	<4B45C9F8.6070608@trueblade.com>
	<94bdd2611001070403u2834bdc3o87eab30dc5c8b7e4@mail.gmail.com>
	<65e0bb521001070652k6925da3ak3a89ca484234f6b5@mail.gmail.com>
	<94bdd2611001070656k3268b2b9n8f5bc2fdab747f3d@mail.gmail.com>
	<65e0bb521001070712o28cd5d92mc46c4fd4fcb4fca@mail.gmail.com>
Message-ID: <4957f1ef1001070829h70f0ecc8m25ddd314ccb1b415@mail.gmail.com>

On Thu, Jan 7, 2010 at 9:12 AM, John Gabriele <jmg3000 at gmail.com> wrote:
> On Thu, Jan 7, 2010 at 9:56 AM, Tarek Ziad? <ziade.tarek at gmail.com> wrote:
>> On Thu, Jan 7, 2010 at 3:52 PM, John Gabriele <jmg3000 at gmail.com> wrote:
>>> The only inconsistency, I think, is that operating systems like Debian
>>> refer to their software distributions as "packages" (as in, a packaged
>>> up piece of software that you can download and install). "Packages" is
>>> a great name for them -- too bad it's already being used in Python.
>>
>> I believe that's basically where the confusion comes from.
>
> Whoops. Just noticed that the front page of the PyPI says:
>
>> "There are currently 8614 packages here."
>
> (is that 8614 packages or 8614 distributions?)
>
> and,
>
>> "To submit a package use "python setup.py upload" and to use a package from this index either "pip install package" or download, unpack and "python setup.py install" it."
>
> and
>
>> "# Browse the tree of packages
> # Submit package information"

Right! The word 'package' is used all over the place, including the
name PyPI abbreviates (Python Package Index), and the title of
PEP-345. Haven't we all also encountered this common usage? I've
noticed in various discussions on this mailing list.

Furthermore, even the official docs make an apology about this
terminology that no one seems to use, stating that the word 'package'
would be preferred but that term is already taken:

From:
> http://docs.python.org/distutils/introduction.html#distutils-specific-terminology

"This would be called a package, except that term is already taken in
the Python context: a single module distribution may contain zero,
one, or many Python packages."

If the official terminology has not caught on in common parlance, is
it really worth maintaining? The word 'package' seems to be what
people want to use, and it is a more accessible term to newbies,
system package maintainers, etc. Rather than waste energy fighting
this popular usage, why not find a solution for this little namespace
conflict?

Of many possible solutions; here are some ideas:

* Make the word 'package' an official replacement for
'module-distribution', without even deprecating the old 'package'
usage for __init__.py directories. English is full of words with
contextual meaning, and people can usually tell by the context which
kind of package is being referred to. After all, that's what's is
happening today. There could be a document clearly stating the
different kinds of packages.

* Use a qualifier, like one of these: 'PyPI Package', 'Setup Package',
'Project Package' while the old kind of package could be qualified as
'Python package' or 'Module Package'.

* Deprecate the old use of 'package' and replace it with another word
such as 'bundle', and try to get it into all Python 3 documentation.

* Introduce a catchy new term to quell the popular tendency to use the
word package instead of 'module-distribution'. Ideas: 'MetaPackage',
'Pkg', 'Porridge', 'Punkage', 'Spankage', 'Spackage', 'Pancake',

From pje at telecommunity.com  Thu Jan  7 17:44:24 2010
From: pje at telecommunity.com (P.J. Eby)
Date: Thu, 07 Jan 2010 11:44:24 -0500
Subject: [Distutils] packaging terminology confusion
In-Reply-To: <4957f1ef1001070829h70f0ecc8m25ddd314ccb1b415@mail.gmail.co
 m>
References: <4957f1ef1001070340y94da3cbgbc6dfe6c05028f3f@mail.gmail.com>
	<4B45C9F8.6070608@trueblade.com>
	<94bdd2611001070403u2834bdc3o87eab30dc5c8b7e4@mail.gmail.com>
	<65e0bb521001070652k6925da3ak3a89ca484234f6b5@mail.gmail.com>
	<94bdd2611001070656k3268b2b9n8f5bc2fdab747f3d@mail.gmail.com>
	<65e0bb521001070712o28cd5d92mc46c4fd4fcb4fca@mail.gmail.com>
	<4957f1ef1001070829h70f0ecc8m25ddd314ccb1b415@mail.gmail.com>
Message-ID: <20100107164433.662DE3A4074@sparrow.telecommunity.com>

At 10:29 AM 1/7/2010 -0600, Brad Allen wrote:
>On Thu, Jan 7, 2010 at 9:12 AM, John Gabriele <jmg3000 at gmail.com> wrote:
> > On Thu, Jan 7, 2010 at 9:56 AM, Tarek Ziad? <ziade.tarek at gmail.com> wrote:
> >> On Thu, Jan 7, 2010 at 3:52 PM, John Gabriele <jmg3000 at gmail.com> wrote:
> >>> The only inconsistency, I think, is that operating systems like Debian
> >>> refer to their software distributions as "packages" (as in, a packaged
> >>> up piece of software that you can download and install). "Packages" is
> >>> a great name for them -- too bad it's already being used in Python.
> >>
> >> I believe that's basically where the confusion comes from.
> >
> > Whoops. Just noticed that the front page of the PyPI says:
> >
> >> "There are currently 8614 packages here."
> >
> > (is that 8614 packages or 8614 distributions?)

8614 *projects*, some of which have one or more *versions*, which in 
turn may have one or more source or binary *distributions*.  That at 
least is the terminology that setuptools and distribute use in their 
documentation at the moment.


From tseaver at palladion.com  Thu Jan  7 19:18:26 2010
From: tseaver at palladion.com (Tres Seaver)
Date: Thu, 07 Jan 2010 13:18:26 -0500
Subject: [Distutils] packaging terminology confusion
In-Reply-To: <4957f1ef1001070340y94da3cbgbc6dfe6c05028f3f@mail.gmail.com>
References: <4957f1ef1001070340y94da3cbgbc6dfe6c05028f3f@mail.gmail.com>
Message-ID: <hi58hh$5el$1@ger.gmane.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Brad Allen wrote:
> This quote is taken from the distutils thread "current preferred way
> to specify dependencies? future?",
> 
> On Wed, Jan 6, 2010 at 10:55 AM, Tarek Ziad? <ziade.tarek at gmail.com> wrote:
>> On Wed, Jan 6, 2010 at 3:35 PM, John Gabriele <jmg3000 at gmail.com> wrote:
>>> I'm a bit confused myself... PEP-345 says it "describes a mechanism
>>> for adding metadata to Python packages", but I think they really mean
>>> "distributions" (the things available at the PyPI).
>> Yes you are right, that was a mistake.  I've just fixed it.
> 
> Sorry, but I'm baffled. Are we really now using the word
> 'distribution' for those 'things available at the PyPI'?
> 
> The text inside PEP-345 uses the word 'distutils project' a lot as the
> name for this concept.
> 
> It's very common to see the word 'package' used to refer to these
> 'distutils projects'; but in the Python documentation we also use the
> word 'package' to refer to any directory having an __init__.py.  Can
> the word 'package' be used for both concepts? Maybe a qualifier would
> help, like module-package and setup-package.
> 
> Normally the word 'distribution' is reserved for what lands in the
> 'dist' directory, such as a tarball or an egg...right?

Here is my take:

 - "pacakge" means a Python package, (directory intended to be on
   sys.path, with an __init__.py.  We *never* mean a distributable
   or installable archive, except when "impedance matching" with folks
   who think in terms of operating system distributions.

 - "distribution" is such a distributable / installable archive: either
   in source form (an 'sdist'), or one of the binary forms (egg., etc.).
   Any distribution may contain multiple packages (or even no packages,
   in the case of standalone scripts).

 - "project" is the process / community which produces releases of
   a given set of software, identified by a name unique within PyPI's
   namespace.  PyPI manages metadata about projects (names, owners) and
   their releases.  Every real project has at least one release.

And another one:

  - "release" is a set of one or more distributions of a project, each
    sharing the same version.  Some PyPI metadata is specific to a
    release, rather than a project.  Every release has at least one
    distribution.



Tres.
- --
===================================================================
Tres Seaver          +1 540-429-0999          tseaver at palladion.com
Palladion Software   "Excellence by Design"    http://palladion.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAktGJW0ACgkQ+gerLs4ltQ6hIwCgndORnbKJc8K2AtJXYSBGv9xW
LEAAn3mrbR64sp/TUm2NIr6YM0pMWJxu
=CeVI
-----END PGP SIGNATURE-----


From jim at zope.com  Thu Jan  7 19:57:21 2010
From: jim at zope.com (Jim Fulton)
Date: Thu, 7 Jan 2010 13:57:21 -0500
Subject: [Distutils] Buildout. Can't start interpreter with -u option.
In-Reply-To: <5bb76e241001041322j797d7f62jb154fa565c5f70e5@mail.gmail.com>
References: <5bb76e241001041322j797d7f62jb154fa565c5f70e5@mail.gmail.com>
Message-ID: <1099b90b1001071057s5eb991dfi2a6ca9a44d201dd8@mail.gmail.com>

On Mon, Jan 4, 2010 at 4:22 PM, ?????? Lacrima <lacrima.maxim at gmail.com> wrote:
> Hello!

Hi, sorry for the late reply.

>
> Suppose I have following buildout.cfg:
>
> [buildout]
> parts = python
> [python]
> recipe = zc.recipe.egg
> interpreter = python
> eggs = mypackage
>
> After running bin/buildout I have python interpreter in bin folder.
> My question is why I can't start the python interpreter with -u option, i.e.
> 'bin/python -u'.
> It fails with the following traceback:
> Traceback (most recent call last):
> ? File "/home/maxim/projects/
> unikeeper/bin/python", line 11, in <module>
> ??? _options, _args = __import__("getopt").getopt(sys.argv[1:], 'ic:m:')
> ? File "/usr/lib/python2.6/getopt.py", line 91, in getopt
> ??? opts, args = do_shorts(opts, args[0][1:], shortopts, args[1:])
> ? File "/usr/lib/python2.6/getopt.py", line 191, in do_shorts
> ??? if short_has_arg(opt, shortopts):
> ? File "/usr/lib/python2.6/getopt.py", line 207, in short_has_arg
> ??? raise GetoptError('option -%s not recognized' % opt, opt)
> getopt.GetoptError: option -u not recognized
>
> Is it a bug?

Perhaps, or perhaps a missing feature. :)

In any case, you're right, the -u option isn't supported.

In the future, I expect support will be added for this as
well as some other unsupported options.

Jim

-- 
Jim Fulton

From floris.bruynooghe at gmail.com  Thu Jan  7 20:44:18 2010
From: floris.bruynooghe at gmail.com (Floris Bruynooghe)
Date: Thu, 7 Jan 2010 19:44:18 +0000
Subject: [Distutils] [RFC] Python 2.7 Distutils extra features
In-Reply-To: <94bdd2611001070725w7eccb2b4s3481c67323f3f4d5@mail.gmail.com>
References: <94bdd2611001060913n2f984e75t5a0943583fe924d2@mail.gmail.com>
	<20100107124418.GA17103@laurie.devork>
	<94bdd2611001070725w7eccb2b4s3481c67323f3f4d5@mail.gmail.com>
Message-ID: <20100107194418.GA14895@laurie.devork>

On Thu, Jan 07, 2010 at 04:25:52PM +0100, Tarek Ziad? wrote:
> On Thu, Jan 7, 2010 at 1:44 PM, Floris Bruynooghe
> <floris.bruynooghe at gmail.com> wrote:
> > Hi Tarek
> >
> > On Wed, Jan 06, 2010 at 06:13:21PM +0100, Tarek Ziad? wrote:
> >> Besides the PEP-related features, I would like to add some tiny
> >> features in Distutils for Python 2.7 before the alpha stage is over :
> >>
> >> - a test command, that just uses the new unittest discovery to run
> >> unittest-compatible tests.
> >
> > Will it be easy to change this to use py.test or nose? ?Or will that
> > just be the normal command overriding mechanism?
> 
> Are you referring to Setuptools' test_suite option ?

No, since I don't know this option.

> Distutils test command could have a similar mechanism, but without the
> auto-installation machinery that comes with Setuptools' one, or the
> entry points. e.g. running test will not install a third-party
> package, and will not do a plugin discovery. So one may pass the name
> of a module or method, like "nose.collector" for delegating the test
> collecting.

Auto-installation definitely seems crazy.  But delegating the test
collecting and test run might be sensible.  I was just wondering for
the case where the package developer uses nose or py.test and a user
just goes for the default "python setup.py test" which then could
produce strange and hard to understand errors.  So by allowing the
developer to specify e.g. py.test as test collector/runner the users
would either have the correct test runner installed and it works, or
would get a meaningful error message like "py.test testrunner
missing".


> But is there a real use case for that ? I mean, you use Nose, can't
> you just run nosetests in the root ?

Sure, but by making it built into distutils (which is a good thing
btw) users will use it even if the developer uses notetests.  Because
no one reads the README's.  ;-)


> Or is this for avoing a PATH manipulation on win32 systems ? where
> sys.prefix+/Scripts is not in PATH.

No idea what specific windows problems would be, sorry.


Regards
Floris

-- 
Debian GNU/Linux -- The Power of Freedom
www.debian.org | www.gnu.org | www.kernel.org

From martin at v.loewis.de  Thu Jan  7 20:53:27 2010
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Thu, 07 Jan 2010 20:53:27 +0100
Subject: [Distutils] current preferred way to specify dependencies?
 future?
In-Reply-To: <3473.165.228.171.167.1262853597.squirrel@syd-srv02.ezyreg.com>
References: <65e0bb521001051929m7674b0co25b707120764a440@mail.gmail.com>
	<1716.218.214.45.58.1262749446.squirrel@syd-srv02.ezyreg.com>
	<4B44254F.4000501@v.loewis.de>
	<3473.165.228.171.167.1262853597.squirrel@syd-srv02.ezyreg.com>
Message-ID: <4B463BB7.2050501@v.loewis.de>

>>> Haven't seen a '386 for over ten years.. Intel have standardised
>>> to calling everything 'Pentium' pretty much since at least 2000.
>> Irrelevant:
> 
> I don't see how it is irrelevent that the constants don't
> map to any 'real' machines on the market.

Why do you say that?

py> import platform
py> platform.machine()
'i686'

'i686' maps very well to a real machine on the market, namely to the
machine on which I'm typing this right now.

>> Whereas using the built-in platform identification mechanism
>> would be extremely difficult?
> 
> The problem is that you can't buy any machine from the shop called
> 'darwin'. You can't buy any notebook/desktop new machine
> with an i386 processor in it.
> 
> Any new kid can't buy a darwin or an i386 notebook.

So what? The kid can type "sys.platform" at the Python prompt,
and then find out what value gets reported.

> We don't use "steam-train" to denote an "ICE" train. It is
> just not right. Sorry.

If you don't like the values that Python reports, get Python
fixed. The PEP will then fix itself automatically, the way
it is specified.

> Starting new PEPs based on erroneous system APIs?

I disagree that the values Python reports are erroneous. They
indicate fairly reliably the relevant characteristics of the
system Python runs on.

Regards,
Martin

From martin at v.loewis.de  Thu Jan  7 21:20:23 2010
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Thu, 07 Jan 2010 21:20:23 +0100
Subject: [Distutils] packaging terminology confusion
In-Reply-To: <20100107164433.662DE3A4074@sparrow.telecommunity.com>
References: <4957f1ef1001070340y94da3cbgbc6dfe6c05028f3f@mail.gmail.com>	<4B45C9F8.6070608@trueblade.com>	<94bdd2611001070403u2834bdc3o87eab30dc5c8b7e4@mail.gmail.com>	<65e0bb521001070652k6925da3ak3a89ca484234f6b5@mail.gmail.com>	<94bdd2611001070656k3268b2b9n8f5bc2fdab747f3d@mail.gmail.com>	<65e0bb521001070712o28cd5d92mc46c4fd4fcb4fca@mail.gmail.com>	<4957f1ef1001070829h70f0ecc8m25ddd314ccb1b415@mail.gmail.com>
	<20100107164433.662DE3A4074@sparrow.telecommunity.com>
Message-ID: <4B464207.3030507@v.loewis.de>

> 8614 *projects*, some of which have one or more *versions*, which in
> turn may have one or more source or binary *distributions*.

Instead of "version", I really like PyPI's term more: *releases*.
As for projects: fine with me; PyPI would then be the Python Project
Index.

Regards,
Martin

From pje at telecommunity.com  Thu Jan  7 21:40:53 2010
From: pje at telecommunity.com (P.J. Eby)
Date: Thu, 07 Jan 2010 15:40:53 -0500
Subject: [Distutils] packaging terminology confusion
In-Reply-To: <4B464207.3030507@v.loewis.de>
References: <4957f1ef1001070340y94da3cbgbc6dfe6c05028f3f@mail.gmail.com>
	<4B45C9F8.6070608@trueblade.com>
	<94bdd2611001070403u2834bdc3o87eab30dc5c8b7e4@mail.gmail.com>
	<65e0bb521001070652k6925da3ak3a89ca484234f6b5@mail.gmail.com>
	<94bdd2611001070656k3268b2b9n8f5bc2fdab747f3d@mail.gmail.com>
	<65e0bb521001070712o28cd5d92mc46c4fd4fcb4fca@mail.gmail.com>
	<4957f1ef1001070829h70f0ecc8m25ddd314ccb1b415@mail.gmail.com>
	<20100107164433.662DE3A4074@sparrow.telecommunity.com>
	<4B464207.3030507@v.loewis.de>
Message-ID: <20100107204102.D121C3A4074@sparrow.telecommunity.com>

At 09:20 PM 1/7/2010 +0100, Martin v. L?wis wrote:
> > 8614 *projects*, some of which have one or more *versions*, which in
> > turn may have one or more source or binary *distributions*.
>
>Instead of "version", I really like PyPI's term more: *releases*.

Not all versions are released versions, so I suppose it's actually:

project -> version -> release -> distribution


>As for projects: fine with me; PyPI would then be the Python Project
>Index.

+1.


From martin at v.loewis.de  Thu Jan  7 22:00:33 2010
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Thu, 07 Jan 2010 22:00:33 +0100
Subject: [Distutils] packaging terminology confusion
In-Reply-To: <20100107204102.D121C3A4074@sparrow.telecommunity.com>
References: <4957f1ef1001070340y94da3cbgbc6dfe6c05028f3f@mail.gmail.com>
	<4B45C9F8.6070608@trueblade.com>
	<94bdd2611001070403u2834bdc3o87eab30dc5c8b7e4@mail.gmail.com>
	<65e0bb521001070652k6925da3ak3a89ca484234f6b5@mail.gmail.com>
	<94bdd2611001070656k3268b2b9n8f5bc2fdab747f3d@mail.gmail.com>
	<65e0bb521001070712o28cd5d92mc46c4fd4fcb4fca@mail.gmail.com>
	<4957f1ef1001070829h70f0ecc8m25ddd314ccb1b415@mail.gmail.com>
	<20100107164433.662DE3A4074@sparrow.telecommunity.com>
	<4B464207.3030507@v.loewis.de>
	<20100107204102.D121C3A4074@sparrow.telecommunity.com>
Message-ID: <4B464B71.9020003@v.loewis.de>

>> Instead of "version", I really like PyPI's term more: *releases*.
> 
> Not all versions are released versions

Actually, from a PyPI point of view, they are :-)

Regards,
Martin

From bradallen137 at gmail.com  Thu Jan  7 22:29:32 2010
From: bradallen137 at gmail.com (Brad Allen)
Date: Thu, 7 Jan 2010 15:29:32 -0600
Subject: [Distutils] packaging terminology confusion
In-Reply-To: <20100107204102.D121C3A4074@sparrow.telecommunity.com>
References: <4957f1ef1001070340y94da3cbgbc6dfe6c05028f3f@mail.gmail.com>
	<4B45C9F8.6070608@trueblade.com>
	<94bdd2611001070403u2834bdc3o87eab30dc5c8b7e4@mail.gmail.com>
	<65e0bb521001070652k6925da3ak3a89ca484234f6b5@mail.gmail.com>
	<94bdd2611001070656k3268b2b9n8f5bc2fdab747f3d@mail.gmail.com>
	<65e0bb521001070712o28cd5d92mc46c4fd4fcb4fca@mail.gmail.com>
	<4957f1ef1001070829h70f0ecc8m25ddd314ccb1b415@mail.gmail.com>
	<20100107164433.662DE3A4074@sparrow.telecommunity.com>
	<4B464207.3030507@v.loewis.de>
	<20100107204102.D121C3A4074@sparrow.telecommunity.com>
Message-ID: <4957f1ef1001071329m2de42256k31581cf2c6d0a1e0@mail.gmail.com>

On Thu, Jan 7, 2010 at 2:40 PM, P.J. Eby <pje at telecommunity.com> wrote:

>> As for projects: fine with me; PyPI would then be the Python Project
>> Index.

+1

If this gets general agreement, there are probably some places where
the word 'package' should be replaced with the word 'project', right?
For example, should PEP-345 be retitled as "Metadata for Python
Software Projects 1.2" ?

From ziade.tarek at gmail.com  Thu Jan  7 22:39:33 2010
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Thu, 7 Jan 2010 22:39:33 +0100
Subject: [Distutils] packaging terminology confusion
In-Reply-To: <4957f1ef1001071329m2de42256k31581cf2c6d0a1e0@mail.gmail.com>
References: <4957f1ef1001070340y94da3cbgbc6dfe6c05028f3f@mail.gmail.com>
	<94bdd2611001070403u2834bdc3o87eab30dc5c8b7e4@mail.gmail.com>
	<65e0bb521001070652k6925da3ak3a89ca484234f6b5@mail.gmail.com>
	<94bdd2611001070656k3268b2b9n8f5bc2fdab747f3d@mail.gmail.com>
	<65e0bb521001070712o28cd5d92mc46c4fd4fcb4fca@mail.gmail.com>
	<4957f1ef1001070829h70f0ecc8m25ddd314ccb1b415@mail.gmail.com>
	<20100107164433.662DE3A4074@sparrow.telecommunity.com>
	<4B464207.3030507@v.loewis.de>
	<20100107204102.D121C3A4074@sparrow.telecommunity.com>
	<4957f1ef1001071329m2de42256k31581cf2c6d0a1e0@mail.gmail.com>
Message-ID: <94bdd2611001071339g15942eb3rcf00dcb8ddd4ee5e@mail.gmail.com>

On Thu, Jan 7, 2010 at 10:29 PM, Brad Allen <bradallen137 at gmail.com> wrote:
> On Thu, Jan 7, 2010 at 2:40 PM, P.J. Eby <pje at telecommunity.com> wrote:
>
>>> As for projects: fine with me; PyPI would then be the Python Project
>>> Index.
>
> +1
>
> If this gets general agreement, there are probably some places where
> the word 'package' should be replaced with the word 'project', right?
> For example, should PEP-345 be retitled as "Metadata for Python
> Software Projects 1.2" ?

+1, we should reflect this terminology in all new PEPs and in
Distutils doc as well

> _______________________________________________
> Distutils-SIG maillist ?- ?Distutils-SIG at python.org
> http://mail.python.org/mailman/listinfo/distutils-sig
>



-- 
Tarek Ziad? | http://ziade.org

From mal at egenix.com  Thu Jan  7 22:51:43 2010
From: mal at egenix.com (M.-A. Lemburg)
Date: Thu, 07 Jan 2010 22:51:43 +0100
Subject: [Distutils] [Catalog-sig]  packaging terminology confusion
In-Reply-To: <94bdd2611001071339g15942eb3rcf00dcb8ddd4ee5e@mail.gmail.com>
References: <4957f1ef1001070340y94da3cbgbc6dfe6c05028f3f@mail.gmail.com>	<94bdd2611001070403u2834bdc3o87eab30dc5c8b7e4@mail.gmail.com>	<65e0bb521001070652k6925da3ak3a89ca484234f6b5@mail.gmail.com>	<94bdd2611001070656k3268b2b9n8f5bc2fdab747f3d@mail.gmail.com>	<65e0bb521001070712o28cd5d92mc46c4fd4fcb4fca@mail.gmail.com>	<4957f1ef1001070829h70f0ecc8m25ddd314ccb1b415@mail.gmail.com>	<20100107164433.662DE3A4074@sparrow.telecommunity.com>	<4B464207.3030507@v.loewis.de>	<20100107204102.D121C3A4074@sparrow.telecommunity.com>	<4957f1ef1001071329m2de42256k31581cf2c6d0a1e0@mail.gmail.com>
	<94bdd2611001071339g15942eb3rcf00dcb8ddd4ee5e@mail.gmail.com>
Message-ID: <4B46576F.7070309@egenix.com>

Tarek Ziad? wrote:
> On Thu, Jan 7, 2010 at 10:29 PM, Brad Allen <bradallen137 at gmail.com> wrote:
>> On Thu, Jan 7, 2010 at 2:40 PM, P.J. Eby <pje at telecommunity.com> wrote:
>>
>>>> As for projects: fine with me; PyPI would then be the Python Project
>>>> Index.
>>
>> +1
>>
>> If this gets general agreement, there are probably some places where
>> the word 'package' should be replaced with the word 'project', right?
>> For example, should PEP-345 be retitled as "Metadata for Python
>> Software Projects 1.2" ?
> 
> +1, we should reflect this terminology in all new PEPs and in
> Distutils doc as well

I don't think we need to change anything - most Python software
components come as Python packages nowadays, so the terminology
'package' we've used all these years is correct.

OTOH, sets of components like Zope are indeed projects. However,
the number of PyPI packages which could reasonably be called a project
is relatively small and even those use Python packages to
separate their namespaces.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Jan 07 2010)
>>> Python/Zope Consulting and Support ...        http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ...             http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...        http://python.egenix.com/
________________________________________________________________________

::: Try our new mxODBC.Connect Python Database Interface for free ! ::::


   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
    D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
           Registered at Amtsgericht Duesseldorf: HRB 46611
               http://www.egenix.com/company/contact/

From bradallen137 at gmail.com  Thu Jan  7 22:57:22 2010
From: bradallen137 at gmail.com (Brad Allen)
Date: Thu, 7 Jan 2010 15:57:22 -0600
Subject: [Distutils] [Catalog-sig]  packaging terminology confusion
In-Reply-To: <4B46576F.7070309@egenix.com>
References: <4957f1ef1001070340y94da3cbgbc6dfe6c05028f3f@mail.gmail.com>
	<94bdd2611001070656k3268b2b9n8f5bc2fdab747f3d@mail.gmail.com>
	<65e0bb521001070712o28cd5d92mc46c4fd4fcb4fca@mail.gmail.com>
	<4957f1ef1001070829h70f0ecc8m25ddd314ccb1b415@mail.gmail.com>
	<20100107164433.662DE3A4074@sparrow.telecommunity.com>
	<4B464207.3030507@v.loewis.de>
	<20100107204102.D121C3A4074@sparrow.telecommunity.com>
	<4957f1ef1001071329m2de42256k31581cf2c6d0a1e0@mail.gmail.com>
	<94bdd2611001071339g15942eb3rcf00dcb8ddd4ee5e@mail.gmail.com>
	<4B46576F.7070309@egenix.com>
Message-ID: <4957f1ef1001071357y382db993qffaee3b5ba2277e2@mail.gmail.com>

On Thu, Jan 7, 2010 at 3:51 PM, M.-A. Lemburg <mal at egenix.com> wrote:

> I don't think we need to change anything - most Python software
> components come as Python packages nowadays, so the terminology
> 'package' we've used all these years is correct.

Do you mean only 'package' in the sense of an __init__.py container,
or in the sense of a setup.py container? Both usages have been in use
for years, but only the __init__.py package was formally recognized.

From stephen.c.waterbury at nasa.gov  Thu Jan  7 22:47:43 2010
From: stephen.c.waterbury at nasa.gov (Stephen Waterbury)
Date: Thu, 7 Jan 2010 16:47:43 -0500
Subject: [Distutils] packaging terminology confusion
In-Reply-To: <4957f1ef1001071329m2de42256k31581cf2c6d0a1e0@mail.gmail.com>
References: <4957f1ef1001070340y94da3cbgbc6dfe6c05028f3f@mail.gmail.com>	<4B45C9F8.6070608@trueblade.com>	<94bdd2611001070403u2834bdc3o87eab30dc5c8b7e4@mail.gmail.com>	<65e0bb521001070652k6925da3ak3a89ca484234f6b5@mail.gmail.com>	<94bdd2611001070656k3268b2b9n8f5bc2fdab747f3d@mail.gmail.com>	<65e0bb521001070712o28cd5d92mc46c4fd4fcb4fca@mail.gmail.com>	<4957f1ef1001070829h70f0ecc8m25ddd314ccb1b415@mail.gmail.com>	<20100107164433.662DE3A4074@sparrow.telecommunity.com>	<4B464207.3030507@v.loewis.de>	<20100107204102.D121C3A4074@sparrow.telecommunity.com>
	<4957f1ef1001071329m2de42256k31581cf2c6d0a1e0@mail.gmail.com>
Message-ID: <4B46567F.5070606@nasa.gov>

Brad Allen wrote:
> On Thu, Jan 7, 2010 at 2:40 PM, P.J. Eby <pje at telecommunity.com> wrote:
> 
>>> As for projects: fine with me; PyPI would then be the Python Project
>>> Index.
> 
> +1
> 
> If this gets general agreement, there are probably some places where
> the word 'package' should be replaced with the word 'project', right?
> For example, should PEP-345 be retitled as "Metadata for Python
> Software Projects 1.2" ?

+1

This makes a huge amount of sense, both from a semantic point of view --
"projects" with "releases" seems a better fit for what is in PyPI --
and as a resolution to the name collision with the Python "package" idiom.

Steve

From mal at egenix.com  Thu Jan  7 23:12:47 2010
From: mal at egenix.com (M.-A. Lemburg)
Date: Thu, 07 Jan 2010 23:12:47 +0100
Subject: [Distutils] [Catalog-sig]  packaging terminology confusion
In-Reply-To: <4957f1ef1001071357y382db993qffaee3b5ba2277e2@mail.gmail.com>
References: <4957f1ef1001070340y94da3cbgbc6dfe6c05028f3f@mail.gmail.com>	<94bdd2611001070656k3268b2b9n8f5bc2fdab747f3d@mail.gmail.com>	<65e0bb521001070712o28cd5d92mc46c4fd4fcb4fca@mail.gmail.com>	<4957f1ef1001070829h70f0ecc8m25ddd314ccb1b415@mail.gmail.com>	<20100107164433.662DE3A4074@sparrow.telecommunity.com>	<4B464207.3030507@v.loewis.de>	<20100107204102.D121C3A4074@sparrow.telecommunity.com>	<4957f1ef1001071329m2de42256k31581cf2c6d0a1e0@mail.gmail.com>	<94bdd2611001071339g15942eb3rcf00dcb8ddd4ee5e@mail.gmail.com>	<4B46576F.7070309@egenix.com>
	<4957f1ef1001071357y382db993qffaee3b5ba2277e2@mail.gmail.com>
Message-ID: <4B465C5F.7030609@egenix.com>

Brad Allen wrote:
> On Thu, Jan 7, 2010 at 3:51 PM, M.-A. Lemburg <mal at egenix.com> wrote:
> 
>> I don't think we need to change anything - most Python software
>> components come as Python packages nowadays, so the terminology
>> 'package' we've used all these years is correct.
> 
> Do you mean only 'package' in the sense of an __init__.py container,
> or in the sense of a setup.py container? Both usages have been in use
> for years, but only the __init__.py package was formally recognized.

We have used the term 'package' for both a Python
software component as well as the Python module directories on
sys.path with a __init__.py marker.

I usually refer to the latter as 'Python package' and the former
as 'package'.

What you download is a 'distribution file' which could be an exe,
a tarball, an egg, etc. There are many forms such a package
distribution can take and just as many ways to install them.

Once installed a 'package' usually creates a single 'Python package'
(at top-level or some lower level).

As a result, after installation there is little difference between
a Python software component called 'package' and the module
directory called 'Python package'. qed :-)

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Jan 07 2010)
>>> Python/Zope Consulting and Support ...        http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ...             http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...        http://python.egenix.com/
________________________________________________________________________

::: Try our new mxODBC.Connect Python Database Interface for free ! ::::


   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
    D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
           Registered at Amtsgericht Duesseldorf: HRB 46611
               http://www.egenix.com/company/contact/

From ziade.tarek at gmail.com  Thu Jan  7 23:22:52 2010
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Thu, 7 Jan 2010 23:22:52 +0100
Subject: [Distutils] [Catalog-sig]  packaging terminology confusion
In-Reply-To: <4B465C5F.7030609@egenix.com>
References: <4957f1ef1001070340y94da3cbgbc6dfe6c05028f3f@mail.gmail.com>
	<4957f1ef1001070829h70f0ecc8m25ddd314ccb1b415@mail.gmail.com>
	<20100107164433.662DE3A4074@sparrow.telecommunity.com>
	<4B464207.3030507@v.loewis.de>
	<20100107204102.D121C3A4074@sparrow.telecommunity.com>
	<4957f1ef1001071329m2de42256k31581cf2c6d0a1e0@mail.gmail.com>
	<94bdd2611001071339g15942eb3rcf00dcb8ddd4ee5e@mail.gmail.com>
	<4B46576F.7070309@egenix.com>
	<4957f1ef1001071357y382db993qffaee3b5ba2277e2@mail.gmail.com>
	<4B465C5F.7030609@egenix.com>
Message-ID: <94bdd2611001071422p56182196mb974e747a0adecd2@mail.gmail.com>

On Thu, Jan 7, 2010 at 11:12 PM, M.-A. Lemburg <mal at egenix.com> wrote:
[..]
> I usually refer to the latter as 'Python package' and the former
> as 'package'.
>
> What you download is a 'distribution file' which could be an exe,
> a tarball, an egg, etc. There are many forms such a package
> distribution can take and just as many ways to install them.

That would be a "release" instead imho. (I like Tres' definitions for that)
e.g. a "release" comes in several "distributions" :  an egg, a source
dist, a binary dist, etc.

>
> Once installed a 'package' usually creates a single 'Python package'
> (at top-level or some lower level).

That's not always the case. Many projects have also scripts, and /or
top level modules in site-packages.

Cheers
Tarek

From pje at telecommunity.com  Fri Jan  8 00:19:28 2010
From: pje at telecommunity.com (P.J. Eby)
Date: Thu, 07 Jan 2010 18:19:28 -0500
Subject: [Distutils] [Catalog-sig]  packaging terminology confusion
In-Reply-To: <4B46576F.7070309@egenix.com>
References: <4957f1ef1001070340y94da3cbgbc6dfe6c05028f3f@mail.gmail.com>
	<94bdd2611001070403u2834bdc3o87eab30dc5c8b7e4@mail.gmail.com>
	<65e0bb521001070652k6925da3ak3a89ca484234f6b5@mail.gmail.com>
	<94bdd2611001070656k3268b2b9n8f5bc2fdab747f3d@mail.gmail.com>
	<65e0bb521001070712o28cd5d92mc46c4fd4fcb4fca@mail.gmail.com>
	<4957f1ef1001070829h70f0ecc8m25ddd314ccb1b415@mail.gmail.com>
	<20100107164433.662DE3A4074@sparrow.telecommunity.com>
	<4B464207.3030507@v.loewis.de>
	<20100107204102.D121C3A4074@sparrow.telecommunity.com>
	<4957f1ef1001071329m2de42256k31581cf2c6d0a1e0@mail.gmail.com>
	<94bdd2611001071339g15942eb3rcf00dcb8ddd4ee5e@mail.gmail.com>
	<4B46576F.7070309@egenix.com>
Message-ID: <20100107231937.8F1293A4108@sparrow.telecommunity.com>

At 10:51 PM 1/7/2010 +0100, M.-A. Lemburg wrote:
>I don't think we need to change anything - most Python software
>components come as Python packages nowadays, so the terminology
>'package' we've used all these years is correct.

Actually, this sentence rather proves the *opposite* point, since 
Brad had to ask which meaning you intended for "packages" in it.  ;-)

(And I confess I was a bit confused myself, since it could be read 
either as a tautology or a dubious proposition, depending on which 
way one took it.)


From fuzzyman at gmail.com  Fri Jan  8 00:52:53 2010
From: fuzzyman at gmail.com (Michael Foord)
Date: Thu, 7 Jan 2010 23:52:53 +0000
Subject: [Distutils] [Catalog-sig]  packaging terminology confusion
In-Reply-To: <20100107204102.D121C3A4074@sparrow.telecommunity.com>
References: <4957f1ef1001070340y94da3cbgbc6dfe6c05028f3f@mail.gmail.com>
	<4B45C9F8.6070608@trueblade.com>
	<94bdd2611001070403u2834bdc3o87eab30dc5c8b7e4@mail.gmail.com>
	<65e0bb521001070652k6925da3ak3a89ca484234f6b5@mail.gmail.com>
	<94bdd2611001070656k3268b2b9n8f5bc2fdab747f3d@mail.gmail.com>
	<65e0bb521001070712o28cd5d92mc46c4fd4fcb4fca@mail.gmail.com>
	<4957f1ef1001070829h70f0ecc8m25ddd314ccb1b415@mail.gmail.com>
	<20100107164433.662DE3A4074@sparrow.telecommunity.com>
	<4B464207.3030507@v.loewis.de>
	<20100107204102.D121C3A4074@sparrow.telecommunity.com>
Message-ID: <6f4025011001071552r980df04w23e3afb5a3efd71a@mail.gmail.com>

2010/1/7 P.J. Eby <pje at telecommunity.com>

> At 09:20 PM 1/7/2010 +0100, Martin v. L?wis wrote:
>
>> > 8614 *projects*, some of which have one or more *versions*, which in
>> > turn may have one or more source or binary *distributions*.
>>
>> Instead of "version", I really like PyPI's term more: *releases*.
>>
>
> Not all versions are released versions, so I suppose it's actually:
>
> project -> version -> release -> distribution
>
>
>
>  As for projects: fine with me; PyPI would then be the Python Project
>> Index.
>>
>
> +1.
>
>
+1 from me as well. It does remove ambiguity.

Michael



>
> _______________________________________________
> Catalog-SIG mailing list
> Catalog-SIG at python.org
> http://mail.python.org/mailman/listinfo/catalog-sig
>



-- 
http://www.ironpythoninaction.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20100107/24ed2c02/attachment.htm>

From nick.bastin at gmail.com  Fri Jan  8 04:19:12 2010
From: nick.bastin at gmail.com (Nicholas Bastin)
Date: Thu, 7 Jan 2010 22:19:12 -0500
Subject: [Distutils] Building extension on FreeBSD with Py_ENABLE_SHARED
Message-ID: <66d0a6e11001071919o21a9a6fey96f4fcb9c8912160@mail.gmail.com>

(This comes from trying to build python with --enable-shared, but I
think the problem is not in the Python build process, but rather in
distutils itself)

When building python standard extensions as part of the build process
from ./configure --enable-shared in 2.7 trunk on freebsd5, all the
modules fail because they can't find libpython2.7.so:

building '_json' extension
gcc -pthread -fPIC -fno-strict-aliasing -DNDEBUG -g -fwrapv -O3 -Wall
-Wstrict-prototypes -I. -I./Include -I/usr/local/include -IInclude
-I/u1/Python/Python-2.7a1 -c /u1/Python/Python-2.7a1/Modules/_json.c
-o build/temp.freebsd-5.3-RELEASE-i386-2.7/u1/Python/Python-2.7a1/Modules/_json.o
gcc -shared build/temp.freebsd-5.3-RELEASE-i386-2.7/u1/Python/Python-2.7a1/Modules/_json.o
-L/usr/local/lib -lpython2.7 -o
build/lib.freebsd-5.3-RELEASE-i386-2.7/_json.so
/usr/bin/ld: cannot find -lpython2.7


This is because libpython2.7.so is in '.' (pre-install), and -L. isn't
on the compile command.  This problem doesn't happen on linux or
solaris, but it turns out that's because it's special-cased in
distutils.command.build_ext.finalize_options:278:

        # for extensions under Linux or Solaris with a shared Python library,
        # Python's library directory must be appended to library_dirs
        sysconfig.get_config_var('Py_ENABLE_SHARED')
        if ((sys.platform.startswith('linux') or sys.platform.startswith('gnu')
             or sys.platform.startswith('sunos'))
            and sysconfig.get_config_var('Py_ENABLE_SHARED')):
            if sys.executable.startswith(os.path.join(sys.exec_prefix, "bin")):
                # building third party extensions
                self.library_dirs.append(sysconfig.get_config_var('LIBDIR'))
            else:
                # building python standard extensions
                self.library_dirs.append('.')

Adding freebsd to the list of platforms in question solves my
particular problem, although I don't know enough about distutils to
know if this would cause some other problem.  Is there any particular
reason we should not add '.' to the list of library_dirs on freebsd?

--
Nick

From jmg3000 at gmail.com  Fri Jan  8 04:43:06 2010
From: jmg3000 at gmail.com (John Gabriele)
Date: Thu, 7 Jan 2010 22:43:06 -0500
Subject: [Distutils] [Catalog-sig]  packaging terminology confusion
In-Reply-To: <94bdd2611001071422p56182196mb974e747a0adecd2@mail.gmail.com>
References: <4957f1ef1001070340y94da3cbgbc6dfe6c05028f3f@mail.gmail.com>
	<20100107164433.662DE3A4074@sparrow.telecommunity.com>
	<4B464207.3030507@v.loewis.de>
	<20100107204102.D121C3A4074@sparrow.telecommunity.com>
	<4957f1ef1001071329m2de42256k31581cf2c6d0a1e0@mail.gmail.com>
	<94bdd2611001071339g15942eb3rcf00dcb8ddd4ee5e@mail.gmail.com>
	<4B46576F.7070309@egenix.com>
	<4957f1ef1001071357y382db993qffaee3b5ba2277e2@mail.gmail.com>
	<4B465C5F.7030609@egenix.com>
	<94bdd2611001071422p56182196mb974e747a0adecd2@mail.gmail.com>
Message-ID: <65e0bb521001071943n7bbf739au3f9c7fc9175c6d01@mail.gmail.com>

On Thu, Jan 7, 2010 at 5:22 PM, Tarek Ziad? <ziade.tarek at gmail.com> wrote:
> On Thu, Jan 7, 2010 at 11:12 PM, M.-A. Lemburg <mal at egenix.com> wrote:
> [..]
>> I usually refer to the latter as 'Python package' and the former
>> as 'package'.
>>
>> What you download is a 'distribution file' which could be an exe,
>> a tarball, an egg, etc. There are many forms such a package
>> distribution can take and just as many ways to install them.
>
> That would be a "release" instead imho. (I like Tres' definitions for that)
> e.g. a "release" comes in several "distributions" : ?an egg, a source
> dist, a binary dist, etc.
>
>>
>> Once installed a 'package' usually creates a single 'Python package'
>> (at top-level or some lower level).
>
> That's not always the case. Many projects have also scripts, and /or
> top level modules in site-packages.

I've got a few brief observations, and also a suggestion.

1. In english, the word "package" can mean an aggregation of features,
as in, "We got married, stayed at a hotel, and got the honeymoon
package. Heart-shaped bed, champagne, and chocolate-covered
strawberries in the fridge!". So, it's a great name for something that
aggregates things, like modules.

2. Also, in english, the word "package" can also mean a nice sealed
box that you send out via or receive from the postal mail. So, it's a
great name for those tgz things that you upload to or download from
the PyPI.

3. People don't like calling those MyProject-1.0.2.tgz thingies
"distributions". They keep calling them packages, and when you correct
them, they say, "[sigh], fine. [eyes roll] 'distribution'."

4. A "project" is just a general term for a named thing that people
work on. "I'm working on my Isengard Reforestation project! I think
it's going to be very successful! I'm keeping it in my
`~/dev/projects/IsengardReforestation` dir." But I don't think
`IsengardReforestation-1.0.2.tgz` would be referred to as a "project"
per se, nor a "project file". A "project file" is one of those things
that an IDE gives you to keep track of which files belong in the
project, how to build it, and so on---so I wouldn't call it that
either.

5. There are already a bunch of tools that refer to those PyPI tgz
things as distributions (for example, Distutils).

6. The word "distribution" is long to type and long to say. And also,
when I think of a Python distribution, I imagine the
`Python-2.6.4.tgz` file you download from python.org. *That's* a
Python distribution (along with the previous Python releases). Also,
ActiveState has a Python distribution too.

So, here's a suggestion: just call both things (packages and
distributions) "packages", but then agree to fully qualify the names
when you need to avoid ambiguity, for example: "I just built a
distribution-package (or "dist-package" for short) and included
numerous module-packages in it."

* If you mean the kind of package holds modules, and the meaning isn't
clear from the context, say "module-package" (think "honeymoon
package")

* If you mean the kind of package hosted at the PyPI, and the meaning
isn't clear from the context, say "distribution-package" or
"dist-package" (think parcel/postal package)

This way,

* The PyPI now becomes the "Python dist-package index", or just
"Python Package Index (PyPI)" for short. :)

* Distutils is now the "distribution-package utilities" or just "dist
utilities" for short. :)

* We can slowly fully-qualify the name "distribution" in the docs,
gradually replacing it with "distribution-package" or "dist-package"
(when it's referring to dist-packages) and it won't be much of a shock
to the system.

How's that sound?

---John

From martin at v.loewis.de  Fri Jan  8 04:58:43 2010
From: martin at v.loewis.de (=?UTF-8?B?Ik1hcnRpbiB2LiBMw7Z3aXMi?=)
Date: Fri, 08 Jan 2010 04:58:43 +0100
Subject: [Distutils] [Catalog-sig]  packaging terminology confusion
In-Reply-To: <65e0bb521001071943n7bbf739au3f9c7fc9175c6d01@mail.gmail.com>
References: <4957f1ef1001070340y94da3cbgbc6dfe6c05028f3f@mail.gmail.com>	<20100107164433.662DE3A4074@sparrow.telecommunity.com>	<4B464207.3030507@v.loewis.de>	<20100107204102.D121C3A4074@sparrow.telecommunity.com>	<4957f1ef1001071329m2de42256k31581cf2c6d0a1e0@mail.gmail.com>	<94bdd2611001071339g15942eb3rcf00dcb8ddd4ee5e@mail.gmail.com>	<4B46576F.7070309@egenix.com>	<4957f1ef1001071357y382db993qffaee3b5ba2277e2@mail.gmail.com>	<4B465C5F.7030609@egenix.com>	<94bdd2611001071422p56182196mb974e747a0adecd2@mail.gmail.com>
	<65e0bb521001071943n7bbf739au3f9c7fc9175c6d01@mail.gmail.com>
Message-ID: <4B46AD73.4000902@v.loewis.de>

> How's that sound?

I read this as a -1 for changing PyPI to use "project".

Still, support *for* renaming it is much wider, it seems.

Regards,
Martin

From jmg3000 at gmail.com  Fri Jan  8 05:30:44 2010
From: jmg3000 at gmail.com (John Gabriele)
Date: Thu, 7 Jan 2010 23:30:44 -0500
Subject: [Distutils] [Catalog-sig] packaging terminology confusion
In-Reply-To: <4B46AD73.4000902@v.loewis.de>
References: <4957f1ef1001070340y94da3cbgbc6dfe6c05028f3f@mail.gmail.com>
	<20100107204102.D121C3A4074@sparrow.telecommunity.com>
	<4957f1ef1001071329m2de42256k31581cf2c6d0a1e0@mail.gmail.com>
	<94bdd2611001071339g15942eb3rcf00dcb8ddd4ee5e@mail.gmail.com>
	<4B46576F.7070309@egenix.com>
	<4957f1ef1001071357y382db993qffaee3b5ba2277e2@mail.gmail.com>
	<4B465C5F.7030609@egenix.com>
	<94bdd2611001071422p56182196mb974e747a0adecd2@mail.gmail.com>
	<65e0bb521001071943n7bbf739au3f9c7fc9175c6d01@mail.gmail.com>
	<4B46AD73.4000902@v.loewis.de>
Message-ID: <65e0bb521001072030t333ab75egac12cd916fa1bd93@mail.gmail.com>

On Thu, Jan 7, 2010 at 10:58 PM, "Martin v. L?wis" <martin at v.loewis.de> wrote:
>> How's that sound?
>
> I read this as a -1 for changing PyPI to use "project".

Well, I'd say not -1, nor +1. I think either name for the PyPI is ok.

I was trying to address the larger issue of confusion of terminology.
I think that no matter what you call the site, in common use users
will still catch themselves saying "get a package from the PyPI",
rather than "get a project from the PyPI". I mean, even some experts
here accidentally refer to distributions as packages.

---John

From fdrake at gmail.com  Fri Jan  8 05:47:05 2010
From: fdrake at gmail.com (Fred Drake)
Date: Thu, 7 Jan 2010 23:47:05 -0500
Subject: [Distutils] [Catalog-sig]  packaging terminology confusion
In-Reply-To: <65e0bb521001071943n7bbf739au3f9c7fc9175c6d01@mail.gmail.com>
References: <4957f1ef1001070340y94da3cbgbc6dfe6c05028f3f@mail.gmail.com> 
	<4B464207.3030507@v.loewis.de>
	<20100107204102.D121C3A4074@sparrow.telecommunity.com> 
	<4957f1ef1001071329m2de42256k31581cf2c6d0a1e0@mail.gmail.com> 
	<94bdd2611001071339g15942eb3rcf00dcb8ddd4ee5e@mail.gmail.com> 
	<4B46576F.7070309@egenix.com>
	<4957f1ef1001071357y382db993qffaee3b5ba2277e2@mail.gmail.com> 
	<4B465C5F.7030609@egenix.com>
	<94bdd2611001071422p56182196mb974e747a0adecd2@mail.gmail.com> 
	<65e0bb521001071943n7bbf739au3f9c7fc9175c6d01@mail.gmail.com>
Message-ID: <9cee7ab81001072047j40946dew9ee32f5231ed1d0@mail.gmail.com>

On Thu, Jan 7, 2010 at 10:43 PM, John Gabriele <jmg3000 at gmail.com> wrote:
> 3. People don't like calling those MyProject-1.0.2.tgz thingies
> "distributions". They keep calling them packages, and when you correct
> them, they say, "[sigh], fine. [eyes roll] 'distribution'."

Interesting.  I've never observed any evidence of that.  Yes, some
people call them packages.  Others call them distributions.  Even
outside the Python realm.

Of course, if you'd rather call them tarballs, I won't mind.  Even if
you don't use tar to make them.  :-)  Or they could be GBOFs (Great
Balls of Fire).

As for the "get a package from the PyPI" verbage, I don't think that's
an issue.  I suspect most distributions include packages rather than a
handful of separate modules these days.  Nor is it wrong to use a
looser term (still widely accepted in the broader community) for the
things gotten from PyPI.

The point of carefully defined terminology is primarily to make sure
that relatively formal communication, such as technical documentation,
can be carried out both effectively and efficiently.  There's no need
to dictate terminology for casual communication, where context is
usually sufficient.


  -Fred

-- 
Fred L. Drake, Jr.    <fdrake at gmail.com>
"Chaos is the score upon which reality is written." --Henry Miller

From jmg3000 at gmail.com  Fri Jan  8 05:47:56 2010
From: jmg3000 at gmail.com (John Gabriele)
Date: Thu, 7 Jan 2010 23:47:56 -0500
Subject: [Distutils] [Catalog-sig]  packaging terminology confusion
In-Reply-To: <65e0bb521001071943n7bbf739au3f9c7fc9175c6d01@mail.gmail.com>
References: <4957f1ef1001070340y94da3cbgbc6dfe6c05028f3f@mail.gmail.com>
	<4B464207.3030507@v.loewis.de>
	<20100107204102.D121C3A4074@sparrow.telecommunity.com>
	<4957f1ef1001071329m2de42256k31581cf2c6d0a1e0@mail.gmail.com>
	<94bdd2611001071339g15942eb3rcf00dcb8ddd4ee5e@mail.gmail.com>
	<4B46576F.7070309@egenix.com>
	<4957f1ef1001071357y382db993qffaee3b5ba2277e2@mail.gmail.com>
	<4B465C5F.7030609@egenix.com>
	<94bdd2611001071422p56182196mb974e747a0adecd2@mail.gmail.com>
	<65e0bb521001071943n7bbf739au3f9c7fc9175c6d01@mail.gmail.com>
Message-ID: <65e0bb521001072047w3b5ef03aub50a926ebad47f16@mail.gmail.com>

On Thu, Jan 7, 2010 at 10:43 PM, John Gabriele <jmg3000 at gmail.com> wrote:
>
> So, here's a suggestion: just call both things (packages and
> distributions) "packages", but then agree to fully qualify the names
> when you need to avoid ambiguity, for example: "I just built a
> distribution-package (or "dist-package" for short) and included
> numerous module-packages in it."
>
> * If you mean the kind of package holds modules, and the meaning isn't
> clear from the context, say "module-package" (think "honeymoon
> package")

Whoops. Looking back through this thread, that last line should probably read:

"""
... say, as Brad A. suggested above, "module-package" ...
"""

---John

From tseaver at palladion.com  Fri Jan  8 07:13:43 2010
From: tseaver at palladion.com (Tres Seaver)
Date: Fri, 08 Jan 2010 01:13:43 -0500
Subject: [Distutils] packaging terminology confusion
In-Reply-To: <9cee7ab81001072047j40946dew9ee32f5231ed1d0@mail.gmail.com>
References: <4957f1ef1001070340y94da3cbgbc6dfe6c05028f3f@mail.gmail.com>
	<4B464207.3030507@v.loewis.de>	<20100107204102.D121C3A4074@sparrow.telecommunity.com>
	<4957f1ef1001071329m2de42256k31581cf2c6d0a1e0@mail.gmail.com>
	<94bdd2611001071339g15942eb3rcf00dcb8ddd4ee5e@mail.gmail.com>
	<4B46576F.7070309@egenix.com>	<4957f1ef1001071357y382db993qffaee3b5ba2277e2@mail.gmail.com>
	<4B465C5F.7030609@egenix.com>	<94bdd2611001071422p56182196mb974e747a0adecd2@mail.gmail.com>
	<65e0bb521001071943n7bbf739au3f9c7fc9175c6d01@mail.gmail.com>
	<9cee7ab81001072047j40946dew9ee32f5231ed1d0@mail.gmail.com>
Message-ID: <hi6iem$qag$2@ger.gmane.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Fred Drake wrote:
> On Thu, Jan 7, 2010 at 10:43 PM, John Gabriele <jmg3000 at gmail.com> wrote:
>> 3. People don't like calling those MyProject-1.0.2.tgz thingies
>> "distributions". They keep calling them packages, and when you correct
>> them, they say, "[sigh], fine. [eyes roll] 'distribution'."
> 
> Interesting.  I've never observed any evidence of that.  Yes, some
> people call them packages.  Others call them distributions.  Even
> outside the Python realm.
> 
> Of course, if you'd rather call them tarballs, I won't mind.  Even if
> you don't use tar to make them.  :-)  Or they could be GBOFs (Great
> Balls of Fire).
> 
> As for the "get a package from the PyPI" verbage, I don't think that's
> an issue.  I suspect most distributions include packages rather than a
> handful of separate modules these days.  Nor is it wrong to use a
> looser term (still widely accepted in the broader community) for the
> things gotten from PyPI.
> 
> The point of carefully defined terminology is primarily to make sure
> that relatively formal communication, such as technical documentation,
> can be carried out both effectively and efficiently.  There's no need
> to dictate terminology for casual communication, where context is
> usually sufficient.

Amen!  Let's go for precision in PEPs, docs, and other spec-like stuff,
and not worry about correcting imprecise-but-easy-to-disambiguate-in-
context usage in ordinary discourse.


Tres.
- --
===================================================================
Tres Seaver          +1 540-429-0999          tseaver at palladion.com
Palladion Software   "Excellence by Design"    http://palladion.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAktGzRcACgkQ+gerLs4ltQ77jQCgxjHfopLzY7b/s6mLYBtb8/d+
WcMAoM7zU+TScc+XFhrHKxF3W8hRNB1m
=sbQz
-----END PGP SIGNATURE-----


From glyph at twistedmatrix.com  Fri Jan  8 07:50:38 2010
From: glyph at twistedmatrix.com (Glyph Lefkowitz)
Date: Fri, 8 Jan 2010 01:50:38 -0500
Subject: [Distutils] [Catalog-sig]  packaging terminology confusion
In-Reply-To: <65e0bb521001071943n7bbf739au3f9c7fc9175c6d01@mail.gmail.com>
References: <4957f1ef1001070340y94da3cbgbc6dfe6c05028f3f@mail.gmail.com>
	<20100107164433.662DE3A4074@sparrow.telecommunity.com>
	<4B464207.3030507@v.loewis.de>
	<20100107204102.D121C3A4074@sparrow.telecommunity.com>
	<4957f1ef1001071329m2de42256k31581cf2c6d0a1e0@mail.gmail.com>
	<94bdd2611001071339g15942eb3rcf00dcb8ddd4ee5e@mail.gmail.com>
	<4B46576F.7070309@egenix.com>
	<4957f1ef1001071357y382db993qffaee3b5ba2277e2@mail.gmail.com>
	<4B465C5F.7030609@egenix.com>
	<94bdd2611001071422p56182196mb974e747a0adecd2@mail.gmail.com>
	<65e0bb521001071943n7bbf739au3f9c7fc9175c6d01@mail.gmail.com>
Message-ID: <723929E9-9814-4005-9025-4F38355DB5E7@twistedmatrix.com>

On Jan 7, 2010, at 10:43 PM, John Gabriele wrote:

> 3. People don't like calling those MyProject-1.0.2.tgz thingies
> "distributions". They keep calling them packages, and when you correct
> them, they say, "[sigh], fine. [eyes roll] 'distribution'."

This is not my experience of the term.  It's more that most people *still* don't know what the term "distribution" means in this context, unless they've extensively read the distutils documentation.  Or that they're talking about Python "distributions" at the same time as what Linux distributions are doing with them, and are trying to avoid being ambiguous.

It sure would be nice if we could use a made-up word like "eggs" to refer to these things.  Too bad that's taken too :-\.

> So, here's a suggestion: just call both things (packages and
> distributions) "packages", but then agree to fully qualify the names
> when you need to avoid ambiguity, for example: "I just built a
> distribution-package (or "dist-package" for short) and included
> numerous module-packages in it."

Except, oops, "dist-package" *also* already has a conflicting jargon meaning as well.  This is what Ubuntu calls "packages distributed by the Linux distribution", i.e. Ubuntu or Debian.  See, for example, <https://lists.ubuntu.com/archives/bazaar/2009q1/054089.html>.  Given that they introduced the term specifically to disambiguate between the things Python already calls "distributions", it seems like introducing the same term to refer to the thing that they were originally talking about would have the opposite effect of what you intend.

Consulting a thesaurus yields one word that nobody has proposed yet: "Parcel".  Helpfully, it still starts with "P", so we could rename it the "Python Parcel Index".  I have a dim memory hearing this word in a jargon-y context before, but it's certainly considerably more obscure than "package", "distribution", "archive", et cetera.

Anybody else like that one?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20100108/b0b9388c/attachment.htm>

From barry at python.org  Fri Jan  8 16:35:39 2010
From: barry at python.org (Barry Warsaw)
Date: Fri, 8 Jan 2010 10:35:39 -0500
Subject: [Distutils] [Catalog-sig]  packaging terminology confusion
In-Reply-To: <4B46AD73.4000902@v.loewis.de>
References: <4957f1ef1001070340y94da3cbgbc6dfe6c05028f3f@mail.gmail.com>
	<20100107164433.662DE3A4074@sparrow.telecommunity.com>
	<4B464207.3030507@v.loewis.de>
	<20100107204102.D121C3A4074@sparrow.telecommunity.com>
	<4957f1ef1001071329m2de42256k31581cf2c6d0a1e0@mail.gmail.com>
	<94bdd2611001071339g15942eb3rcf00dcb8ddd4ee5e@mail.gmail.com>
	<4B46576F.7070309@egenix.com>
	<4957f1ef1001071357y382db993qffaee3b5ba2277e2@mail.gmail.com>
	<4B465C5F.7030609@egenix.com>
	<94bdd2611001071422p56182196mb974e747a0adecd2@mail.gmail.com>
	<65e0bb521001071943n7bbf739au3f9c7fc9175c6d01@mail.gmail.com>
	<4B46AD73.4000902@v.loewis.de>
Message-ID: <20100108103539.20bd564c@freewill>

On Jan 08, 2010, at 04:58 AM, Martin v. L?wis wrote:

>I read this as a -1 for changing PyPI to use "project".
>
>Still, support *for* renaming it is much wider, it seems.

I wish there was a humorous, ironic name for the service that is evocative of
the Python language's original conceit.  Something that at first glance says
"we should have lots of tasty morsels to offer here", then "oh, sorry, the
cat's eaten them".  The irony of course being that indeed we /do/ have lots of
delicious comestibles for peckish Pythonistas to consume.  Something much
catchier that can't be confused with a homonym for an entirely different
project in the Python world.

venezuelan-beaver-cheese-ly y'rs,
-Barry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20100108/df9b8e26/attachment.pgp>

From jmg3000 at gmail.com  Fri Jan  8 16:40:41 2010
From: jmg3000 at gmail.com (John Gabriele)
Date: Fri, 8 Jan 2010 10:40:41 -0500
Subject: [Distutils] [Catalog-sig] packaging terminology confusion
In-Reply-To: <723929E9-9814-4005-9025-4F38355DB5E7@twistedmatrix.com>
References: <4957f1ef1001070340y94da3cbgbc6dfe6c05028f3f@mail.gmail.com>
	<20100107204102.D121C3A4074@sparrow.telecommunity.com>
	<4957f1ef1001071329m2de42256k31581cf2c6d0a1e0@mail.gmail.com>
	<94bdd2611001071339g15942eb3rcf00dcb8ddd4ee5e@mail.gmail.com>
	<4B46576F.7070309@egenix.com>
	<4957f1ef1001071357y382db993qffaee3b5ba2277e2@mail.gmail.com>
	<4B465C5F.7030609@egenix.com>
	<94bdd2611001071422p56182196mb974e747a0adecd2@mail.gmail.com>
	<65e0bb521001071943n7bbf739au3f9c7fc9175c6d01@mail.gmail.com>
	<723929E9-9814-4005-9025-4F38355DB5E7@twistedmatrix.com>
Message-ID: <65e0bb521001080740o4e09a0f1ib49e8ec555ec611c@mail.gmail.com>

On Fri, Jan 8, 2010 at 1:50 AM, Glyph Lefkowitz <glyph at twistedmatrix.com> wrote:
> On Jan 7, 2010, at 10:43 PM, John Gabriele wrote:
>
> 3. People don't like calling those MyProject-1.0.2.tgz thingies
> "distributions". They keep calling them packages, and when you correct
> them, they say, "[sigh], fine. [eyes roll] 'distribution'."
>
> This is not my experience of the term. ?It's more that most people *still*
> don't know what the term "distribution" means in this context, unless
> they've extensively read the distutils documentation. ?Or that they're
> talking about Python "distributions" at the same time as what Linux
> distributions are doing with them, and are trying to avoid being ambiguous.

Hm. Well, it's possible I'm reading too much into online commentary
while wearing my cheese-colored glasses.

> It sure would be nice if we could use a made-up word like "eggs" to refer to
> these things. ?Too bad that's taken too :-\.

If there's a desire to replace the word "distribution" (meaning, the
tgz's at the PyPI) in the technical docs to increase clarity, then
your suggestion of "parcel" is certainly good. Another might be
"bundle" (though, that one's used on Mac OS X in connection with
shared libs, I think).

I like saying "Python distribution" to mean the big archive file you
download to install Python on your system.

Of course, the PyPI could be renamed "Python Project Index" regardless
of the technical name used for Fred's GBOFs. :)

I also think that the instructions on the front page of the PyPI could
say "usage: `pip install ProjectName` or `python setup.py install
ProjectName`" and it would be clear, again, regardless of what the
technical name of GBOFs are.

Re. Barry's recent comment:
>
> I wish there was a humorous, ironic name for the service that is evocative of
> {snip}

Could always come up with such a name, and still use "The Python
Project Index" as the main *subtitle*.

---John

From waterbug at pangalactic.us  Fri Jan  8 16:51:27 2010
From: waterbug at pangalactic.us (Stephen Waterbury)
Date: Fri, 08 Jan 2010 10:51:27 -0500
Subject: [Distutils] [Catalog-sig]  packaging terminology confusion
In-Reply-To: <20100108103539.20bd564c@freewill>
References: <4957f1ef1001070340y94da3cbgbc6dfe6c05028f3f@mail.gmail.com>	<20100107164433.662DE3A4074@sparrow.telecommunity.com>	<4B464207.3030507@v.loewis.de>	<20100107204102.D121C3A4074@sparrow.telecommunity.com>	<4957f1ef1001071329m2de42256k31581cf2c6d0a1e0@mail.gmail.com>	<94bdd2611001071339g15942eb3rcf00dcb8ddd4ee5e@mail.gmail.com>	<4B46576F.7070309@egenix.com>	<4957f1ef1001071357y382db993qffaee3b5ba2277e2@mail.gmail.com>	<4B465C5F.7030609@egenix.com>	<94bdd2611001071422p56182196mb974e747a0adecd2@mail.gmail.com>	<65e0bb521001071943n7bbf739au3f9c7fc9175c6d01@mail.gmail.com>	<4B46AD73.4000902@v.loewis.de>
	<20100108103539.20bd564c@freewill>
Message-ID: <4B47547F.5090303@pangalactic.us>

Barry Warsaw wrote:
> I wish there was a humorous, ironic name for the service that is evocative of
> the Python language's original conceit.  Something that at first glance says
> "we should have lots of tasty morsels to offer here", then "oh, sorry, the
> cat's eaten them".  The irony of course being that indeed we /do/ have lots of
> delicious comestibles for peckish Pythonistas to consume.  Something much
> catchier that can't be confused with a homonym for an entirely different
> project in the Python world.
> 
> venezuelan-beaver-cheese-ly y'rs,
> -Barry

Yes, I too wish we had such a name ... hmmm ...  :)
That would give us a whole domain of names for packaging
concepts ... of course, things might become a bit cheesy at
that point!  ;)

"Blessed are the cheese-makers!"  :D

maybe-its-south-american-beavers-in-generally y'rs,
Steve

From regebro at gmail.com  Fri Jan  8 17:29:30 2010
From: regebro at gmail.com (Lennart Regebro)
Date: Fri, 8 Jan 2010 17:29:30 +0100
Subject: [Distutils] [Catalog-sig] packaging terminology confusion
In-Reply-To: <4B47547F.5090303@pangalactic.us>
References: <4957f1ef1001070340y94da3cbgbc6dfe6c05028f3f@mail.gmail.com>
	<94bdd2611001071339g15942eb3rcf00dcb8ddd4ee5e@mail.gmail.com>
	<4B46576F.7070309@egenix.com>
	<4957f1ef1001071357y382db993qffaee3b5ba2277e2@mail.gmail.com>
	<4B465C5F.7030609@egenix.com>
	<94bdd2611001071422p56182196mb974e747a0adecd2@mail.gmail.com>
	<65e0bb521001071943n7bbf739au3f9c7fc9175c6d01@mail.gmail.com>
	<4B46AD73.4000902@v.loewis.de> <20100108103539.20bd564c@freewill>
	<4B47547F.5090303@pangalactic.us>
Message-ID: <319e029f1001080829w4a140dedr48e0d4dce249caed@mail.gmail.com>

Just my 2 cents:

- The definitions that Tarek proposed it exactly how I already use the words.
- I think Python Project Index is a better name than Python Package
Index. But Cheese Shop is still better. :)

That's all I have to say about it. :-)

-- 
Lennart Regebro: Python, Zope, Plone, Grok
http://regebro.wordpress.com/
+33 661 58 14 64

From bradallen137 at gmail.com  Fri Jan  8 18:00:28 2010
From: bradallen137 at gmail.com (Brad Allen)
Date: Fri, 8 Jan 2010 11:00:28 -0600
Subject: [Distutils] [Catalog-sig] packaging terminology confusion
In-Reply-To: <319e029f1001080829w4a140dedr48e0d4dce249caed@mail.gmail.com>
References: <4957f1ef1001070340y94da3cbgbc6dfe6c05028f3f@mail.gmail.com>
	<4B46576F.7070309@egenix.com>
	<4957f1ef1001071357y382db993qffaee3b5ba2277e2@mail.gmail.com>
	<4B465C5F.7030609@egenix.com>
	<94bdd2611001071422p56182196mb974e747a0adecd2@mail.gmail.com>
	<65e0bb521001071943n7bbf739au3f9c7fc9175c6d01@mail.gmail.com>
	<4B46AD73.4000902@v.loewis.de> <20100108103539.20bd564c@freewill>
	<4B47547F.5090303@pangalactic.us>
	<319e029f1001080829w4a140dedr48e0d4dce249caed@mail.gmail.com>
Message-ID: <4957f1ef1001080900h52f271ccg45f71f376592db79@mail.gmail.com>

On Fri, Jan 8, 2010 at 10:29 AM, Lennart Regebro <regebro at gmail.com> wrote:
> Just my 2 cents:
>
> - The definitions that Tarek proposed it exactly how I already use the words.
> - I think Python Project Index is a better name than Python Package
> Index. But Cheese Shop is still better. :)
>
> That's all I have to say about it. :-)

I also liked the 'CheeseShop' name, but what does that leave our
setup.py thingies being called? Cheeseballs, maybe?

> Consulting a thesaurus yields one word that nobody has proposed yet:
> "Parcel".  Helpfully, it still starts with "P", so we could rename it the
> "Python Parcel Index".  I have a dim memory hearing this word in a jargon-y
> context before, but it's certainly considerably more obscure than "package",
> "distribution", "archive", et cetera.
> Anybody else like that one?

Yes, very much. I like 'parcel' better than 'project', partly because
it's not already overload with other contextual meanings.

While visiting Bangalore recently, I had some trouble asking for
'to-go' orders at restaurants. Nobody seemed to understand what that
meant. Finally I learned that Indians say 'parcel' when they want a
food order to go. A 'parcel' is usually bag containing all the rice,
gravy, napkins, bread, sporks you need to create an edible
distribution of items on your table at home.

From pje at telecommunity.com  Fri Jan  8 18:44:55 2010
From: pje at telecommunity.com (P.J. Eby)
Date: Fri, 08 Jan 2010 12:44:55 -0500
Subject: [Distutils] [Catalog-sig] packaging terminology confusion
In-Reply-To: <4957f1ef1001080900h52f271ccg45f71f376592db79@mail.gmail.co
 m>
References: <4957f1ef1001070340y94da3cbgbc6dfe6c05028f3f@mail.gmail.com>
	<4B46576F.7070309@egenix.com>
	<4957f1ef1001071357y382db993qffaee3b5ba2277e2@mail.gmail.com>
	<4B465C5F.7030609@egenix.com>
	<94bdd2611001071422p56182196mb974e747a0adecd2@mail.gmail.com>
	<65e0bb521001071943n7bbf739au3f9c7fc9175c6d01@mail.gmail.com>
	<4B46AD73.4000902@v.loewis.de> <20100108103539.20bd564c@freewill>
	<4B47547F.5090303@pangalactic.us>
	<319e029f1001080829w4a140dedr48e0d4dce249caed@mail.gmail.com>
	<4957f1ef1001080900h52f271ccg45f71f376592db79@mail.gmail.com>
Message-ID: <20100108174506.B2C473A4074@sparrow.telecommunity.com>

At 11:00 AM 1/8/2010 -0600, Brad Allen wrote:
>On Fri, Jan 8, 2010 at 10:29 AM, Lennart Regebro <regebro at gmail.com> wrote:
> > Just my 2 cents:
> >
> > - The definitions that Tarek proposed it exactly how I already 
> use the words.
> > - I think Python Project Index is a better name than Python Package
> > Index. But Cheese Shop is still better. :)
> >
> > That's all I have to say about it. :-)
>
>I also liked the 'CheeseShop' name, but what does that leave our
>setup.py thingies being called? Cheeseballs, maybe?
>
> > Consulting a thesaurus yields one word that nobody has proposed yet:
> > "Parcel".  Helpfully, it still starts with "P", so we could rename it the
> > "Python Parcel Index".  I have a dim memory hearing this word in a jargon-y
> > context before, but it's certainly considerably more obscure than 
> "package",
> > "distribution", "archive", et cetera.
> > Anybody else like that one?
>
>Yes, very much. I like 'parcel' better than 'project', partly because
>it's not already overload with other contextual meanings.

This is just another example of the degree of confusion around 
terminology here, because "parcel" isn't a substitute for "project": 
a "project" is something that you would release "parcels" *for*.


From tseaver at palladion.com  Fri Jan  8 22:22:51 2010
From: tseaver at palladion.com (Tres Seaver)
Date: Fri, 08 Jan 2010 16:22:51 -0500
Subject: [Distutils] [Catalog-sig] packaging terminology confusion
In-Reply-To: <319e029f1001080829w4a140dedr48e0d4dce249caed@mail.gmail.com>
References: <4957f1ef1001070340y94da3cbgbc6dfe6c05028f3f@mail.gmail.com>	<94bdd2611001071339g15942eb3rcf00dcb8ddd4ee5e@mail.gmail.com>	<4B46576F.7070309@egenix.com>	<4957f1ef1001071357y382db993qffaee3b5ba2277e2@mail.gmail.com>	<4B465C5F.7030609@egenix.com>	<94bdd2611001071422p56182196mb974e747a0adecd2@mail.gmail.com>	<65e0bb521001071943n7bbf739au3f9c7fc9175c6d01@mail.gmail.com>	<4B46AD73.4000902@v.loewis.de>
	<20100108103539.20bd564c@freewill>	<4B47547F.5090303@pangalactic.us>
	<319e029f1001080829w4a140dedr48e0d4dce249caed@mail.gmail.com>
Message-ID: <hi87nc$8fv$1@ger.gmane.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Lennart Regebro wrote:
> Just my 2 cents:
> 
> - The definitions that Tarek proposed it exactly how I already use the words.
> - I think Python Project Index is a better name than Python Package
> Index. But Cheese Shop is still better. :)
> 
> That's all I have to say about it. :-)

/me longs for a wheel of Cheddar to go with his XML parser.


Tres.
- --
===================================================================
Tres Seaver          +1 540-429-0999          tseaver at palladion.com
Palladion Software   "Excellence by Design"    http://palladion.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAktHoisACgkQ+gerLs4ltQ5W5ACgtsKKVWlDfRQHLL71oRKM8DmK
EDgAn1kTf2eJMEm2n7t/alPxJ/zmy5nn
=+OqI
-----END PGP SIGNATURE-----


From floris.bruynooghe at gmail.com  Sat Jan  9 01:01:24 2010
From: floris.bruynooghe at gmail.com (Floris Bruynooghe)
Date: Sat, 9 Jan 2010 00:01:24 +0000
Subject: [Distutils] [Catalog-sig]  packaging terminology confusion
In-Reply-To: <20100108103539.20bd564c@freewill>
References: <20100107204102.D121C3A4074@sparrow.telecommunity.com>
	<4957f1ef1001071329m2de42256k31581cf2c6d0a1e0@mail.gmail.com>
	<94bdd2611001071339g15942eb3rcf00dcb8ddd4ee5e@mail.gmail.com>
	<4B46576F.7070309@egenix.com>
	<4957f1ef1001071357y382db993qffaee3b5ba2277e2@mail.gmail.com>
	<4B465C5F.7030609@egenix.com>
	<94bdd2611001071422p56182196mb974e747a0adecd2@mail.gmail.com>
	<65e0bb521001071943n7bbf739au3f9c7fc9175c6d01@mail.gmail.com>
	<4B46AD73.4000902@v.loewis.de> <20100108103539.20bd564c@freewill>
Message-ID: <20100109000124.GA13536@laurie.devork>

On Fri, Jan 08, 2010 at 10:35:39AM -0500, Barry Warsaw wrote:
> On Jan 08, 2010, at 04:58 AM, Martin v. L?wis wrote:
> 
> >I read this as a -1 for changing PyPI to use "project".
> >
> >Still, support *for* renaming it is much wider, it seems.
> 
> I wish there was a humorous, ironic name for the service that is evocative of
> the Python language's original conceit.  Something that at first glance says
> "we should have lots of tasty morsels to offer here", then "oh, sorry, the
> cat's eaten them".  The irony of course being that indeed we /do/ have lots of
> delicious comestibles for peckish Pythonistas to consume.  Something much
> catchier that can't be confused with a homonym for an entirely different
> project in the Python world.
> 
> venezuelan-beaver-cheese-ly y'rs,
> -Barry

+10


Floris

From olaf at conradi.org  Sat Jan  9 01:28:15 2010
From: olaf at conradi.org (Olaf Conradi)
Date: Sat, 9 Jan 2010 01:28:15 +0100
Subject: [Distutils] zc.buildout generated console scripts with sys.exit
Message-ID: <118246c11001081628g4f4dc0ecnccae5c66646fd5c6@mail.gmail.com>

Hello,

I wanted use zc.buildout for a program that I wrote, but noticed that the
generated console script does not call sys.exit, unlike setuptools.

My main function uses a structure as explained by Guido in
http://www.artima.com/weblogs/viewpost.jsp?thread=4829

def main(argv=None):
    if argv is None:
        argv = sys.argv
    # ...
    return 0

if __name__ == "__main__":
    sys.exit(main())


Can this be supported?

I noticed a patch is attached to
https://bugs.launchpad.net/zc.buildout/+bug/164629

In short, my buildout looks like this:

[py]
recipe = zc.recipe.egg
eggs = myprogram


Thanks,
 -Olaf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20100109/0a2f192e/attachment.htm>

From olaf at conradi.name  Sat Jan  9 01:24:29 2010
From: olaf at conradi.name (Olaf Conradi)
Date: Sat, 9 Jan 2010 01:24:29 +0100
Subject: [Distutils] zc.buildout generated console scripts with sys.exit
Message-ID: <118246c11001081624k5b0f9fcdq9145c2df8907d7f0@mail.gmail.com>

Hello,

I wanted use zc.buildout for a program that I wrote, but noticed that the
generated console script does not call sys.exit, unlike setuptools.

My main function uses a structure as explained by Guido in
http://www.artima.com/weblogs/viewpost.jsp?thread=4829

def main(argv=None):
    if argv is None:
        argv = sys.argv
    # ...
    return 0

if __name__ == "__main__":
    sys.exit(main())


Can this be supported?

I noticed a patch is attached to
https://bugs.launchpad.net/zc.buildout/+bug/164629

In short, my buildout looks like this:

[py]
recipe = zc.recipe.egg
eggs = myprogram


Thanks,
 -Olaf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20100109/f2297a40/attachment.htm>

From floris.bruynooghe at gmail.com  Sat Jan  9 11:04:42 2010
From: floris.bruynooghe at gmail.com (Floris Bruynooghe)
Date: Sat, 9 Jan 2010 10:04:42 +0000
Subject: [Distutils] Building extension on FreeBSD with Py_ENABLE_SHARED
In-Reply-To: <66d0a6e11001071919o21a9a6fey96f4fcb9c8912160@mail.gmail.com>
References: <66d0a6e11001071919o21a9a6fey96f4fcb9c8912160@mail.gmail.com>
Message-ID: <20100109100442.GA25072@laurie.devork>

Hi Nicholas

On Thu, Jan 07, 2010 at 10:19:12PM -0500, Nicholas Bastin wrote:
> (This comes from trying to build python with --enable-shared, but I
> think the problem is not in the Python build process, but rather in
> distutils itself)
> 
> When building python standard extensions as part of the build process
> from ./configure --enable-shared in 2.7 trunk on freebsd5, all the
> modules fail because they can't find libpython2.7.so:

Searching throug the tracker I found this:
http://bugs.python.org/issue4366, which looks the same issue.


> This is because libpython2.7.so is in '.' (pre-install), and -L. isn't
> on the compile command.  This problem doesn't happen on linux or
> solaris, but it turns out that's because it's special-cased in
> distutils.command.build_ext.finalize_options:278:
> 
>         # for extensions under Linux or Solaris with a shared Python library,
>         # Python's library directory must be appended to library_dirs
>         sysconfig.get_config_var('Py_ENABLE_SHARED')
>         if ((sys.platform.startswith('linux') or sys.platform.startswith('gnu')
>              or sys.platform.startswith('sunos'))
>             and sysconfig.get_config_var('Py_ENABLE_SHARED')):
>             if sys.executable.startswith(os.path.join(sys.exec_prefix, "bin")):
>                 # building third party extensions
>                 self.library_dirs.append(sysconfig.get_config_var('LIBDIR'))
>             else:
>                 # building python standard extensions
>                 self.library_dirs.append('.')
> 
> Adding freebsd to the list of platforms in question solves my
> particular problem, although I don't know enough about distutils to
> know if this would cause some other problem.  Is there any particular
> reason we should not add '.' to the list of library_dirs on freebsd?

Your solution is better tough, If you don't I'll try to create and
test a patch for it by the end of the weekend.

Regards
Floris

-- 
Debian GNU/Linux -- The Power of Freedom
www.debian.org | www.gnu.org | www.kernel.org

From bradallen137 at gmail.com  Sat Jan  9 16:13:36 2010
From: bradallen137 at gmail.com (Brad Allen)
Date: Sat, 9 Jan 2010 09:13:36 -0600
Subject: [Distutils] [Catalog-sig] packaging terminology confusion
In-Reply-To: <20100108174506.B2C473A4074@sparrow.telecommunity.com>
References: <4957f1ef1001070340y94da3cbgbc6dfe6c05028f3f@mail.gmail.com>
	<4B465C5F.7030609@egenix.com>
	<94bdd2611001071422p56182196mb974e747a0adecd2@mail.gmail.com>
	<65e0bb521001071943n7bbf739au3f9c7fc9175c6d01@mail.gmail.com>
	<4B46AD73.4000902@v.loewis.de> <20100108103539.20bd564c@freewill>
	<4B47547F.5090303@pangalactic.us>
	<319e029f1001080829w4a140dedr48e0d4dce249caed@mail.gmail.com>
	<4957f1ef1001080900h52f271ccg45f71f376592db79@mail.gmail.com>
	<20100108174506.B2C473A4074@sparrow.telecommunity.com>
Message-ID: <4957f1ef1001090713l1ca97cd0k8254e9ed3ae4e34e@mail.gmail.com>

On Fri, Jan 8, 2010 at 11:44 AM, P.J. Eby <pje at telecommunity.com> wrote:

>>
>> Yes, very much. I like 'parcel' better than 'project', partly because
>> it's not already overload with other contextual meanings.
>
> This is just another example of the degree of confusion around terminology
> here, because "parcel" isn't a substitute for "project": a "project" is
> something that you would release "parcels" *for*.

These two terms have yet to be formally adopted, so they can mean what
we want them to mean. As you mentioned earlier the word 'project' has
been adopted by setuptool documentation, but this discussion shows the
distutils community is still in a process of deciding the best
terminology.

The word 'project' has two other meanings which are already in common
use within the general developer community, one being an IDE document
(such as a WingIDE project file), the other being a process/community
as Tres described earlier. Also, M. Lemburg noted that a 'project'
often is meant to refer to a grouping of software components (such as
Zope), but not the individual software component.

'Project' is still a good candidate word and has gotten a lot of
positive votes on this thread, but that was before Glyph suggested
'parcel', which I prefer for the following reasons:

* It does not compete with any existing meanings in the community, and
seems relatively untouched by the software community at large
* The non-software meaning comes close to the non-software meaning of
'package', which most have agreed is a natural fit for setup.py
thingies but has generated confusion because of other meanings.
* Search engine queries for "Python parcel" are likely not to be
buried in something unrelate. Even now, a Google search for "Python
parsel" shows this discussion on the first page (though not at the
top).
* It is adequately non-silly to satisfy whoever (regretfully) renamed
the Cheeseshop to PyPI, yet .nonconformist enough for the "And now for
something completely different" faction.
* Saying 'Python parcel' is fun, refreshing, and soon to be
non-ambiguous if we choose to adopt that term.

Does anyone who vote +1 for 'project' want to change that vote to
'parcel'? I do.

From bradallen137 at gmail.com  Sat Jan  9 16:23:56 2010
From: bradallen137 at gmail.com (Brad Allen)
Date: Sat, 9 Jan 2010 09:23:56 -0600
Subject: [Distutils] [Catalog-sig]  packaging terminology confusion
In-Reply-To: <9cee7ab81001072047j40946dew9ee32f5231ed1d0@mail.gmail.com>
References: <4957f1ef1001070340y94da3cbgbc6dfe6c05028f3f@mail.gmail.com>
	<20100107204102.D121C3A4074@sparrow.telecommunity.com>
	<4957f1ef1001071329m2de42256k31581cf2c6d0a1e0@mail.gmail.com>
	<94bdd2611001071339g15942eb3rcf00dcb8ddd4ee5e@mail.gmail.com>
	<4B46576F.7070309@egenix.com>
	<4957f1ef1001071357y382db993qffaee3b5ba2277e2@mail.gmail.com>
	<4B465C5F.7030609@egenix.com>
	<94bdd2611001071422p56182196mb974e747a0adecd2@mail.gmail.com>
	<65e0bb521001071943n7bbf739au3f9c7fc9175c6d01@mail.gmail.com>
	<9cee7ab81001072047j40946dew9ee32f5231ed1d0@mail.gmail.com>
Message-ID: <4957f1ef1001090723m659e36cbv220b02e6285744b1@mail.gmail.com>

On Thu, Jan 7, 2010 at 10:47 PM, Fred Drake <fdrake at gmail.com> wrote:

> The point of carefully defined terminology is primarily to make sure
> that relatively formal communication, such as technical documentation,
> can be carried out both effectively and efficiently. ?There's no need
> to dictate terminology for casual communication, where context is
> usually sufficient.

Fred Drake said:
> The point of carefully defined terminology is primarily to make sure
> that relatively formal communication, such as technical documentation,
> can be carried out both effectively and efficiently.

Nevertheless, formal terminology imost useful when it agrees with
common usage; after all, we also want informal discussion (such as we
have on distutils, everyday work, user groups, etc.) to be effective
and efficient. In this case the formal terminology is so cumbersome
that people tend not to use in technical documentation.

>There's no need
> to dictate terminology for casual communication, where context is
> usually sufficient.

Ah, well we can't dictate that anyway, can we? This is a negotiation,
not an attempt to dictate. People will say what they want to say. The
goal here is to improve the formal terminology and change it in the
documentation, in such a way that informal discussions are more likely
to adopt the formal terminology and to be consistent with the
documentation.

From pje at telecommunity.com  Sat Jan  9 17:38:52 2010
From: pje at telecommunity.com (P.J. Eby)
Date: Sat, 09 Jan 2010 11:38:52 -0500
Subject: [Distutils] [Catalog-sig] packaging terminology confusion
In-Reply-To: <4957f1ef1001090713l1ca97cd0k8254e9ed3ae4e34e@mail.gmail.co
 m>
References: <4957f1ef1001070340y94da3cbgbc6dfe6c05028f3f@mail.gmail.com>
	<4B465C5F.7030609@egenix.com>
	<94bdd2611001071422p56182196mb974e747a0adecd2@mail.gmail.com>
	<65e0bb521001071943n7bbf739au3f9c7fc9175c6d01@mail.gmail.com>
	<4B46AD73.4000902@v.loewis.de> <20100108103539.20bd564c@freewill>
	<4B47547F.5090303@pangalactic.us>
	<319e029f1001080829w4a140dedr48e0d4dce249caed@mail.gmail.com>
	<4957f1ef1001080900h52f271ccg45f71f376592db79@mail.gmail.com>
	<20100108174506.B2C473A4074@sparrow.telecommunity.com>
	<4957f1ef1001090713l1ca97cd0k8254e9ed3ae4e34e@mail.gmail.com>
Message-ID: <20100109163905.4671C3A4074@sparrow.telecommunity.com>

At 09:13 AM 1/9/2010 -0600, Brad Allen wrote:
>On Fri, Jan 8, 2010 at 11:44 AM, P.J. Eby <pje at telecommunity.com> wrote:
>
> >>
> >> Yes, very much. I like 'parcel' better than 'project', partly because
> >> it's not already overload with other contextual meanings.
> >
> > This is just another example of the degree of confusion around terminology
> > here, because "parcel" isn't a substitute for "project": a "project" is
> > something that you would release "parcels" *for*.
>
>These two terms have yet to be formally adopted, so they can mean what
>we want them to mean.

You miss my point: the usage of "project" you were commenting on was 
not in reference to the same thing as your comment.  In the context 
of the thread, "project" was referring to "thing that has releases" 
and "parcel" was being used as a substitute for the existing term 
"distribution" or "module distribution".

(And even if it's *me* who's confused here, the point still stands 
about the degree of confusion.  ;-) )

Anyway, IMO "parcel" works great as a substitute for "distribution" 
(as it is a concrete term for a concrete thing) and not so great as a 
substitute for "project" (since a project isn't that concrete a thing 
and "parcel" therefore seems *too* concrete).


From jim at zope.com  Sat Jan  9 17:59:50 2010
From: jim at zope.com (Jim Fulton)
Date: Sat, 9 Jan 2010 11:59:50 -0500
Subject: [Distutils] zc.buildout generated console scripts with sys.exit
In-Reply-To: <118246c11001081628g4f4dc0ecnccae5c66646fd5c6@mail.gmail.com>
References: <118246c11001081628g4f4dc0ecnccae5c66646fd5c6@mail.gmail.com>
Message-ID: <1099b90b1001090859p441f2d80rb31a5c1f88a515b@mail.gmail.com>

On Fri, Jan 8, 2010 at 7:28 PM, Olaf Conradi <olaf at conradi.org> wrote:
> Hello,
>
> I wanted use zc.buildout for a program that I wrote, but noticed that the
> generated console script does not call sys.exit, unlike setuptools.
>
> My main function uses a structure as explained by Guido in
> http://www.artima.com/weblogs/viewpost.jsp?thread=4829
>
> def main(argv=None):
>     if argv is None:
>         argv = sys.argv
>     # ...
>     return 0
>
> if __name__ == "__main__":
>     sys.exit(main())
>
> Can this be supported?

Yup. This will be in a future release.

I've resisted this in the past, because I'd never seen the return
value of main specified before and there's a long tradition of main
functions returning None (by not returning anything), but I see that
sys.exit treats None the same as 0.

> I noticed a patch is attached to
> https://bugs.launchpad.net/zc.buildout/+bug/164629

Unfortunately, this patch doesn't include a test, although updating
the tests will be trivial, since applying the patch will make existing
tests fail. (Maybe one of the other buildout maintainers will get it
done before me. :)

Jim

-- 
Jim Fulton

From nick.bastin at gmail.com  Sat Jan  9 18:05:15 2010
From: nick.bastin at gmail.com (Nicholas Bastin)
Date: Sat, 9 Jan 2010 12:05:15 -0500
Subject: [Distutils] Building extension on FreeBSD with Py_ENABLE_SHARED
In-Reply-To: <20100109100442.GA25072@laurie.devork>
References: <66d0a6e11001071919o21a9a6fey96f4fcb9c8912160@mail.gmail.com>
	<20100109100442.GA25072@laurie.devork>
Message-ID: <66d0a6e11001090905v51a3f4b9v55c788e7116ae24e@mail.gmail.com>

On Sat, Jan 9, 2010 at 05:04, Floris Bruynooghe
<floris.bruynooghe at gmail.com> wrote:
> Your solution is better tough, If you don't I'll try to create and
> test a patch for it by the end of the weekend.

I'll put a patch on that issue today.  I've tested on freebsd5 and it
works - I'd like to at least test on freebsd6, and if someone else has
access to more modern versions, that would be good to test as well.

--
Nick

From nick.bastin at gmail.com  Sat Jan  9 18:59:12 2010
From: nick.bastin at gmail.com (Nicholas Bastin)
Date: Sat, 9 Jan 2010 12:59:12 -0500
Subject: [Distutils] Building extension on FreeBSD with Py_ENABLE_SHARED
In-Reply-To: <20100109100442.GA25072@laurie.devork>
References: <66d0a6e11001071919o21a9a6fey96f4fcb9c8912160@mail.gmail.com>
	<20100109100442.GA25072@laurie.devork>
Message-ID: <66d0a6e11001090959v7f985d26y8c9ef2cc97276987@mail.gmail.com>

On Sat, Jan 9, 2010 at 05:04, Floris Bruynooghe
<floris.bruynooghe at gmail.com> wrote:
> Searching throug the tracker I found this:
> http://bugs.python.org/issue4366, which looks the same issue.

I've added a patch from 2.7 and comment to this issue (apologies for
failing to find it on my first seach).  I'm grabbing a checkout of 3.2
trunk now so I can make a patch there as well.

Which leaves only a few questions:

* Does anyone think this isn't the proper fix?
* Should it be patched in 26-maint and 31-maint as well?

--
Nick

From martin at v.loewis.de  Sat Jan  9 19:23:17 2010
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Sat, 09 Jan 2010 19:23:17 +0100
Subject: [Distutils] Building extension on FreeBSD with Py_ENABLE_SHARED
In-Reply-To: <66d0a6e11001090959v7f985d26y8c9ef2cc97276987@mail.gmail.com>
References: <66d0a6e11001071919o21a9a6fey96f4fcb9c8912160@mail.gmail.com>	<20100109100442.GA25072@laurie.devork>
	<66d0a6e11001090959v7f985d26y8c9ef2cc97276987@mail.gmail.com>
Message-ID: <4B48C995.3030400@v.loewis.de>

> * Should it be patched in 26-maint and 31-maint as well?

I think so, yes. Adding new support for --enable-shared would be out
of scope; fixing the existing support is fine.

Regards,
Martin

From suno.ano at sunoano.org  Sat Jan  9 19:36:26 2010
From: suno.ano at sunoano.org (Suno Ano)
Date: Sat, 09 Jan 2010 19:36:26 +0100
Subject: [Distutils] [Catalog-sig] packaging terminology confusion
References: <4957f1ef1001070340y94da3cbgbc6dfe6c05028f3f@mail.gmail.com>
	<4B465C5F.7030609@egenix.com>
	<94bdd2611001071422p56182196mb974e747a0adecd2@mail.gmail.com>
	<65e0bb521001071943n7bbf739au3f9c7fc9175c6d01@mail.gmail.com>
	<4B46AD73.4000902@v.loewis.de> <20100108103539.20bd564c@freewill>
	<4B47547F.5090303@pangalactic.us>
	<319e029f1001080829w4a140dedr48e0d4dce249caed@mail.gmail.com>
	<4957f1ef1001080900h52f271ccg45f71f376592db79@mail.gmail.com>
	<20100108174506.B2C473A4074@sparrow.telecommunity.com>
	<4957f1ef1001090713l1ca97cd0k8254e9ed3ae4e34e@mail.gmail.com>
Message-ID: <874omv9lcl.fsf@wks.lan>


[skipping a lot of lines ...]

 Brad> Does anyone who vote +1 for 'project' want to change that vote to
 Brad> 'parcel'?

I do
http://tarekziade.wordpress.com/2010/01/07/fixing-packaging-terminology-confusion

 - However, as P.J. Eby pointed out correctly, *parcel* would be a
   substitute for *distribution* and not for *project*.
   http://mail.python.org/pipermail/distutils-sig/2010-January/015282.html

 - Alexander Limi also has a good point, using the term *installers*
   that is. We should consider that one too I think.




From bradallen137 at gmail.com  Sat Jan  9 19:47:06 2010
From: bradallen137 at gmail.com (Brad Allen)
Date: Sat, 9 Jan 2010 12:47:06 -0600
Subject: [Distutils] [Catalog-sig] packaging terminology confusion
In-Reply-To: <20100109163905.4671C3A4074@sparrow.telecommunity.com>
References: <4957f1ef1001070340y94da3cbgbc6dfe6c05028f3f@mail.gmail.com>
	<65e0bb521001071943n7bbf739au3f9c7fc9175c6d01@mail.gmail.com>
	<4B46AD73.4000902@v.loewis.de> <20100108103539.20bd564c@freewill>
	<4B47547F.5090303@pangalactic.us>
	<319e029f1001080829w4a140dedr48e0d4dce249caed@mail.gmail.com>
	<4957f1ef1001080900h52f271ccg45f71f376592db79@mail.gmail.com>
	<20100108174506.B2C473A4074@sparrow.telecommunity.com>
	<4957f1ef1001090713l1ca97cd0k8254e9ed3ae4e34e@mail.gmail.com>
	<20100109163905.4671C3A4074@sparrow.telecommunity.com>
Message-ID: <4957f1ef1001091047i661d79c1tfeb379386d95989a@mail.gmail.com>

On Sat, Jan 9, 2010 at 10:38 AM, P.J. Eby <pje at telecommunity.com> wrote:
> At 09:13 AM 1/9/2010 -0600, Brad Allen wrote:
>>
>> On Fri, Jan 8, 2010 at 11:44 AM, P.J. Eby <pje at telecommunity.com> wrote:
>>
>> >>
>> >> Yes, very much. I like 'parcel' better than 'project', partly because
>> >> it's not already overload with other contextual meanings.
>> >
>> > This is just another example of the degree of confusion around
>> > terminology
>> > here, because "parcel" isn't a substitute for "project": a "project" is
>> > something that you would release "parcels" *for*.
>>
>> These two terms have yet to be formally adopted, so they can mean what
>> we want them to mean.
>
> You miss my point: the usage of "project" you were commenting on was not in
> reference to the same thing as your comment. ?In the context of the thread,
> "project" was referring to "thing that has releases" and "parcel" was being
> used as a substitute for the existing term "distribution" or "module
> distribution".
>
> (And even if it's *me* who's confused here, the point still stands about the
> degree of confusion. ?;-) )
>
> Anyway, IMO "parcel" works great as a substitute for "distribution" (as it
> is a concrete term for a concrete thing) and not so great as a substitute
> for "project" (since a project isn't that concrete a thing and "parcel"
> therefore seems *too* concrete).

No, I am certainly the more confused party. I have not fully thought
through all the concepts under consideration here.

Up till now I've been thinking that we have been trying to come up
with the right name of a concrete thing: a directory containing a
setup.py, along with source code and resources needed to generate the
file in the 'dist' directory. That is why 'parcel' started to seem
attractive.

Now I understand that your 'project' concept probably corresponds to
an entry in PyPI which is associated with multiple releases (each
release having a set of downloadable files available, formally called
'distributions' or 'module distributions', but informally called
'packages'.)  The word 'project' is not a suitable replacement for the
word 'package', because 'project' is a higher level abstract container
of releases, not a downloadable file containing a setup.py.

Back to the problem at hand: why is the term 'package' is so
ubiquitously used instead of 'module distribution', despite the
ambiguity? And what can the community do to reduce the ambiguity?

Here's a theory:

When you have a release ready, what do you do with it? You 'package'
it, of course. You don't 'project' it, and you don't 'parcel' it. What
is the result of the 'packaging' activity? It's a 'package' of course.

Thought of in this way, it's understandable why the term 'package'
keeps getting used despite well-meaning efforts to call it something
else, and names like 'module distribution' or a 'parcel' probably
won't catch on.

Maybe it's just wrong to call the __init__.py directories 'packages',
because they are really just a piece of what is getting packaged.
Also, in the physical world, a 'package' is a thing you distribute. Do
we ever distribute an __init__.py directory by its lonesome? No! It
doesn't have any packaging around it.

I am starting to feel twinges of animosity toward the use of the word
'package' for these barenaked, poor defenseless __init__.py
directories. Why can't we do a better job of defending our __init__.py
thingies from wrongful packaging terminology?





Frequently in the README of an entry in PyPI, I see instructions for
"installing this package".



Of course, the other concept is the entry in PyPI, which encompasses
multiple releases (but not necessarily all versions), though the UI
normally only displays the latest release. Normally the entry in PyPI
has docs stating "Installing this Package"

The concept which seems to be missing the right word is the directory
containing the setup.py and other resources needed to build a
distribution. Every time you change the version in the setup.py, it's
just a different version of the same thing.

I am have a

From bradallen137 at gmail.com  Sat Jan  9 19:51:16 2010
From: bradallen137 at gmail.com (Brad Allen)
Date: Sat, 9 Jan 2010 12:51:16 -0600
Subject: [Distutils] [Catalog-sig] packaging terminology confusion
In-Reply-To: <4957f1ef1001091047i661d79c1tfeb379386d95989a@mail.gmail.com>
References: <4957f1ef1001070340y94da3cbgbc6dfe6c05028f3f@mail.gmail.com>
	<4B46AD73.4000902@v.loewis.de> <20100108103539.20bd564c@freewill>
	<4B47547F.5090303@pangalactic.us>
	<319e029f1001080829w4a140dedr48e0d4dce249caed@mail.gmail.com>
	<4957f1ef1001080900h52f271ccg45f71f376592db79@mail.gmail.com>
	<20100108174506.B2C473A4074@sparrow.telecommunity.com>
	<4957f1ef1001090713l1ca97cd0k8254e9ed3ae4e34e@mail.gmail.com>
	<20100109163905.4671C3A4074@sparrow.telecommunity.com>
	<4957f1ef1001091047i661d79c1tfeb379386d95989a@mail.gmail.com>
Message-ID: <4957f1ef1001091051p6f700bb9i27c43b5143bcc907@mail.gmail.com>

Oops, I hit send too soon. Please ignore my prior message which
contain scratch text at the end. The corrected message follows:

On Sat, Jan 9, 2010 at 10:38 AM, P.J. Eby <pje at telecommunity.com> wrote:
> At 09:13 AM 1/9/2010 -0600, Brad Allen wrote:
>>
>> On Fri, Jan 8, 2010 at 11:44 AM, P.J. Eby <pje at telecommunity.com> wrote:
>>
>> >>
>> >> Yes, very much. I like 'parcel' better than 'project', partly because
>> >> it's not already overload with other contextual meanings.
>> >
>> > This is just another example of the degree of confusion around
>> > terminology
>> > here, because "parcel" isn't a substitute for "project": a "project" is
>> > something that you would release "parcels" *for*.
>>
>> These two terms have yet to be formally adopted, so they can mean what
>> we want them to mean.
>
> You miss my point: the usage of "project" you were commenting on was not in
> reference to the same thing as your comment.  In the context of the thread,
> "project" was referring to "thing that has releases" and "parcel" was being
> used as a substitute for the existing term "distribution" or "module
> distribution".
>
> (And even if it's *me* who's confused here, the point still stands about the
> degree of confusion.  ;-) )
>
> Anyway, IMO "parcel" works great as a substitute for "distribution" (as it
> is a concrete term for a concrete thing) and not so great as a substitute
> for "project" (since a project isn't that concrete a thing and "parcel"
> therefore seems *too* concrete).

No, I am certainly the more confused party. I have not fully thought
through all the concepts under consideration here.

Up till now I've been thinking that we have been trying to come up
with the right name of a concrete thing: a directory containing a
setup.py, along with source code and resources needed to generate the
file in the 'dist' directory. That is why 'parcel' started to seem
attractive.

Now I understand that your 'project' concept probably corresponds to
an entry in PyPI which is associated with multiple releases (each
release having a set of downloadable files available, formally called
'distributions' or 'module distributions', but informally called
'packages'.)  The word 'project' is not a suitable replacement for the
word 'package', because 'project' is a higher level abstract container
of releases, not a downloadable file containing a setup.py.

Back to the problem at hand: why is the term 'package' so
ubiquitously used instead of 'module distribution', despite the
ambiguity? And what can the community do to reduce the ambiguity?

Here's a theory:

When you have a release ready, what do you do with it? You 'package'
it, of course. You don't 'project' it, and you don't 'parcel' it. What
is the result of the 'packaging' activity? It's a 'package' of course.

Thought of in this way, it's understandable why the term 'package'
keeps getting used despite well-meaning efforts to call it something
else, and names like 'module distribution' or a 'parcel' probably
won't catch on.

Maybe it's just wrong to call the __init__.py directories 'packages',
because they are really just a piece of what is getting packaged.
Also, in the physical world, a 'package' is a thing you distribute. Do
we ever distribute an __init__.py directory by its lonesome? No! It
doesn't have any packaging around it.

I am starting to feel twinges of animosity toward the use of the word
'package' for these barenaked, poor defenseless __init__.py
directories. Why can't we do a better job of defending our __init__.py
thingies from wrongful packaging terminology?

From suno.ano at sunoano.org  Sat Jan  9 20:17:07 2010
From: suno.ano at sunoano.org (Suno Ano)
Date: Sat, 09 Jan 2010 20:17:07 +0100
Subject: [Distutils] [Catalog-sig] packaging terminology confusion
References: <4957f1ef1001070340y94da3cbgbc6dfe6c05028f3f@mail.gmail.com>
	<4B46AD73.4000902@v.loewis.de> <20100108103539.20bd564c@freewill>
	<4B47547F.5090303@pangalactic.us>
	<319e029f1001080829w4a140dedr48e0d4dce249caed@mail.gmail.com>
	<4957f1ef1001080900h52f271ccg45f71f376592db79@mail.gmail.com>
	<20100108174506.B2C473A4074@sparrow.telecommunity.com>
	<4957f1ef1001090713l1ca97cd0k8254e9ed3ae4e34e@mail.gmail.com>
	<20100109163905.4671C3A4074@sparrow.telecommunity.com>
	<4957f1ef1001091047i661d79c1tfeb379386d95989a@mail.gmail.com>
	<4957f1ef1001091051p6f700bb9i27c43b5143bcc907@mail.gmail.com>
Message-ID: <87ljg784wc.fsf@wks.lan>


[skipping a lot of lines ...]

Brad> called 'packages'.) The word 'project' is not a suitable
Brad> replacement for the word 'package',

right, imho it is been never considered to be

Brad> because 'project' is a higher level abstract container of
Brad> releases, not a downloadable file containing a setup.py.

I would rather thing of project as some sort of
namespace/process/community than being a container. Well container and
namespace are maybe the same thing here so we might have the same
understanding after all. Here is mine:

 - *package* means a Python package, (directory intended to be on
   sys.path, with an __init__.py. We *never* mean a distributable
   or installable archive, except when ?impedance matching? with
   folks who think in terms of operating system parcels.

 - *parcel* is such a distributable / installable archive:
   either in source form (an ?sdist?), or one of the binary
   forms (egg., etc.). Any parcel may contain multiple
   packages (or even no packages, in the case of standalone
   scripts).

 - *project* is the process / community which produces releases of
   a given set of software, identified by a name unique within
   PyPI?s namespace. PyPI manages metadata about projects (names,
   owners) and their releases. Every real project has at least
   one release.

 - *release* is a set of one or more parcels of a project,
   each sharing the same version. Some PyPI metadata is specific
   to a release, rather than a project. Every release has at
   least one parcel.

 - *installer* is an OS specific piece of software provides by
   some project which usually installs a Python interpreter and
   other general software in order to have some Python
   application installed from scratch.



From regebro at gmail.com  Sat Jan  9 20:48:36 2010
From: regebro at gmail.com (Lennart Regebro)
Date: Sat, 9 Jan 2010 20:48:36 +0100
Subject: [Distutils] [Catalog-sig] packaging terminology confusion
In-Reply-To: <87ljg784wc.fsf@wks.lan>
References: <4957f1ef1001070340y94da3cbgbc6dfe6c05028f3f@mail.gmail.com>
	<4B47547F.5090303@pangalactic.us>
	<319e029f1001080829w4a140dedr48e0d4dce249caed@mail.gmail.com>
	<4957f1ef1001080900h52f271ccg45f71f376592db79@mail.gmail.com>
	<20100108174506.B2C473A4074@sparrow.telecommunity.com>
	<4957f1ef1001090713l1ca97cd0k8254e9ed3ae4e34e@mail.gmail.com>
	<20100109163905.4671C3A4074@sparrow.telecommunity.com>
	<4957f1ef1001091047i661d79c1tfeb379386d95989a@mail.gmail.com>
	<4957f1ef1001091051p6f700bb9i27c43b5143bcc907@mail.gmail.com>
	<87ljg784wc.fsf@wks.lan>
Message-ID: <319e029f1001091148j3c6a929g6867a89efb5da776@mail.gmail.com>

On Sat, Jan 9, 2010 at 20:17, Suno Ano <suno.ano at sunoano.org> wrote:
> ?- *package* means a Python package, (directory intended to be on
> ? sys.path, with an __init__.py. We *never* mean a distributable
> ? or installable archive, except when ?impedance matching? with
> ? folks who think in terms of operating system parcels.
>
> ?- *parcel* is such a distributable / installable archive:
> ? either in source form (an ?sdist?), or one of the binary
> ? forms (egg., etc.). Any parcel may contain multiple
> ? packages (or even no packages, in the case of standalone
> ? scripts).
>
> ?- *project* is the process / community which produces releases of
> ? a given set of software, identified by a name unique within
> ? PyPI?s namespace. PyPI manages metadata about projects (names,
> ? owners) and their releases. Every real project has at least
> ? one release.
>
> ?- *release* is a set of one or more parcels of a project,
> ? each sharing the same version. Some PyPI metadata is specific
> ? to a release, rather than a project. Every release has at
> ? least one parcel.
>
> ?- *installer* is an OS specific piece of software provides by
> ? some project which usually installs a Python interpreter and
> ? other general software in order to have some Python
> ? application installed from scratch.

Yes. Again, exactly how I use the words already. This is the same for
all intents and purposes as Tareks proposal, this is how the words are
being used already in practice.

-- 
Lennart Regebro: Python, Zope, Plone, Grok
http://regebro.wordpress.com/
+33 661 58 14 64

From olaf at conradi.org  Sun Jan 10 00:01:45 2010
From: olaf at conradi.org (Olaf Conradi)
Date: Sun, 10 Jan 2010 00:01:45 +0100
Subject: [Distutils] buildout config question
Message-ID: <118246c11001091501r2ac46367je763ce08ec6f9d1b@mail.gmail.com>

Hello,

Am fiddling with a buildout.cfg for my project, but I don't understand
something in script generation.
It seems my console script is generated twice.
And in that second round it adds pylint to the script of my program
and not just the pylint script??

This is the config I have

My setup.py contains:
setup(
??? # ..
??? entry_points="""
???????????????? [console_scripts]
???????????????? bank2ledger = bank2ledger.main:main
???????????????? """
)

My buildout.cfg

[buildout]
develop = .
parts = bank2ledger pylint
# pyxdg is not available in PyPI
find-links = http://www.freedesktop.org/~lanius/pyxdg-0.18.tar.gz

[bank2ledger]
recipe = zc.recipe.egg:scripts
eggs =
??? bank2ledger
??? pyxdg

[pylint]
recipe = zc.recipe.egg
eggs =
??? pylint
??? ${bank2ledger:eggs}
entry-points = pylint=pylint.lint:Run
arguments = sys.argv[1:]+[
??? '--output-format=parseable',
??? 'bank2ledger']

Running buildout:

$ ./bin/buildout
Develop: '/home/olaf/Project/Bank2Ledger/.'
Updating bank2ledger.
Generated script '/home/olaf/Project/Bank2Ledger/bin/bank2ledger'.
Updating pylint.
Generated script '/home/olaf/Project/Bank2Ledger/bin/bank2ledger'.

When it creates my script the first time it is what I want:

import sys
sys.path[0:0] = [
  '/home/olaf/Project/Bank2Ledger/src',
  '/home/olaf/Project/Bank2Ledger/eggs/pyxdg-0.18-py2.5.egg',
# [snip] a lot more dependencies
  ]

import bank2ledger.main

if __name__ == '__main__':
    bank2ledger.main.main()

However, this scipt is overwitten by the pylint part with:

import sys
sys.path[0:0] = [
  '/home/olaf/Project/Bank2Ledger/eggs/pylint-0.19.0-py2.5.egg',
  '/home/olaf/Project/Bank2Ledger/src',
# [snip], same list of dependencies as above
  ]

import bank2ledger.main

if __name__ == '__main__':
    bank2ledger.main.main(sys.argv[1:]+[
'--output-format=parseable',
'bank2ledger'])


But those arguments I wanted the bin/pylint script to have, not the
main entry point of my program.

The bin/pylint script is what I expect it to be.

How come the bank2ledger script is generated twice?
Am I misunderstanding how to use zc.buildout?

Thanks,
 -Olaf

From jmg3000 at gmail.com  Sun Jan 10 00:04:40 2010
From: jmg3000 at gmail.com (John Gabriele)
Date: Sat, 9 Jan 2010 18:04:40 -0500
Subject: [Distutils] [Catalog-sig] packaging terminology confusion
In-Reply-To: <319e029f1001091148j3c6a929g6867a89efb5da776@mail.gmail.com>
References: <4957f1ef1001070340y94da3cbgbc6dfe6c05028f3f@mail.gmail.com>
	<319e029f1001080829w4a140dedr48e0d4dce249caed@mail.gmail.com>
	<4957f1ef1001080900h52f271ccg45f71f376592db79@mail.gmail.com>
	<20100108174506.B2C473A4074@sparrow.telecommunity.com>
	<4957f1ef1001090713l1ca97cd0k8254e9ed3ae4e34e@mail.gmail.com>
	<20100109163905.4671C3A4074@sparrow.telecommunity.com>
	<4957f1ef1001091047i661d79c1tfeb379386d95989a@mail.gmail.com>
	<4957f1ef1001091051p6f700bb9i27c43b5143bcc907@mail.gmail.com>
	<87ljg784wc.fsf@wks.lan>
	<319e029f1001091148j3c6a929g6867a89efb5da776@mail.gmail.com>
Message-ID: <65e0bb521001091504m43dd8ccctd3e41231033971c0@mail.gmail.com>

On Sat, Jan 9, 2010 at 2:48 PM, Lennart Regebro <regebro at gmail.com> wrote:
> On Sat, Jan 9, 2010 at 20:17, Suno Ano <suno.ano at sunoano.org> wrote:
>
>> ?- *package* means a Python package, (directory intended to be on
>> ? sys.path, with an __init__.py. We *never* mean a distributable
>> ? or installable archive, except when ?impedance matching? with
>> ? folks who think in terms of operating system parcels.
>>
>> ?- *parcel* is such a distributable / installable archive:
>> ? either in source form (an ?sdist?), or one of the binary
>> ? forms (egg., etc.). Any parcel may contain multiple
>> ? packages (or even no packages, in the case of standalone
>> ? scripts).
>>
>> ?- *project* is the process / community which produces releases of
>> ? a given set of software, identified by a name unique within
>> ? PyPI?s namespace. PyPI manages metadata about projects (names,
>> ? owners) and their releases. Every real project has at least
>> ? one release.
>>
>> ?- *release* is a set of one or more parcels of a project,
>> ? each sharing the same version. Some PyPI metadata is specific
>> ? to a release, rather than a project. Every release has at
>> ? least one parcel.
>>
>> ?- *installer* is an OS specific piece of software provides by
>> ? some project which usually installs a Python interpreter and
>> ? other general software in order to have some Python
>> ? application installed from scratch.
>
> Yes. Again, exactly how I use the words already. This is the same for
> all intents and purposes as Tareks proposal, this is how the words are
> being used already in practice.

I would also add the common use of the term "distribution" to that
glossary as well.

At http://python.org/download/ , that big software archive that you
download, unpack, and install---giving you a Python installed on your
system---is referred to as a "distribution". Ex., "the python.org
Python distribution", "the ActiveState Python distribution", etc.

Enthought calls theirs a distribution as well:
http://enthought.com/products/epd.php

Incidentally, Perl calls theirs distributions too:
http://www.cpan.org/ (source code distribution available here
http://www.cpan.org/src/README.html ).

Ruby calls theirs distributions as well http://www.ruby-lang.org/en/downloads/ .

---John

From suno.ano at sunoano.org  Sun Jan 10 00:37:43 2010
From: suno.ano at sunoano.org (Suno Ano)
Date: Sun, 10 Jan 2010 00:37:43 +0100
Subject: [Distutils] packaging terminology confusion
References: <4957f1ef1001070340y94da3cbgbc6dfe6c05028f3f@mail.gmail.com>
	<319e029f1001080829w4a140dedr48e0d4dce249caed@mail.gmail.com>
	<4957f1ef1001080900h52f271ccg45f71f376592db79@mail.gmail.com>
	<20100108174506.B2C473A4074@sparrow.telecommunity.com>
	<4957f1ef1001090713l1ca97cd0k8254e9ed3ae4e34e@mail.gmail.com>
	<20100109163905.4671C3A4074@sparrow.telecommunity.com>
	<4957f1ef1001091047i661d79c1tfeb379386d95989a@mail.gmail.com>
	<4957f1ef1001091051p6f700bb9i27c43b5143bcc907@mail.gmail.com>
	<87ljg784wc.fsf@wks.lan>
	<319e029f1001091148j3c6a929g6867a89efb5da776@mail.gmail.com>
	<65e0bb521001091504m43dd8ccctd3e41231033971c0@mail.gmail.com>
Message-ID: <871vhy7su0.fsf@wks.lan>

 John> I would also add the common use of the term "distribution" to
 John> that glossary as well.

Yes, true that, at http://python.org/download/ we have *distributions*
to download.

I figure the definition for *Installer* should then include that term
too. To summarize, we now have the terms

 - package
 - parcel
 - project
 - release
 - installer
 - distribution

Do others agree? Is something missing? Something wrong with that point
of view?


From glyph at twistedmatrix.com  Sun Jan 10 10:01:14 2010
From: glyph at twistedmatrix.com (Glyph Lefkowitz)
Date: Sun, 10 Jan 2010 04:01:14 -0500
Subject: [Distutils] [Catalog-sig] packaging terminology confusion
In-Reply-To: <20100109163905.4671C3A4074@sparrow.telecommunity.com>
References: <4957f1ef1001070340y94da3cbgbc6dfe6c05028f3f@mail.gmail.com>
	<4B465C5F.7030609@egenix.com>
	<94bdd2611001071422p56182196mb974e747a0adecd2@mail.gmail.com>
	<65e0bb521001071943n7bbf739au3f9c7fc9175c6d01@mail.gmail.com>
	<4B46AD73.4000902@v.loewis.de> <20100108103539.20bd564c@freewill>
	<4B47547F.5090303@pangalactic.us>
	<319e029f1001080829w4a140dedr48e0d4dce249caed@mail.gmail.com>
	<4957f1ef1001080900h52f271ccg45f71f376592db79@mail.gmail.com>
	<20100108174506.B2C473A4074@sparrow.telecommunity.com>
	<4957f1ef1001090713l1ca97cd0k8254e9ed3ae4e34e@mail.gmail.com>
	<20100109163905.4671C3A4074@sparrow.telecommunity.com>
Message-ID: <49F3FD7D-00FF-48E0-88C8-7A753941BC15@twistedmatrix.com>


On Jan 9, 2010, at 11:38 AM, P.J. Eby wrote:

> Anyway, IMO "parcel" works great as a substitute for "distribution" (as it is a concrete term for a concrete thing) and not so great as a substitute for "project" (since a project isn't that concrete a thing and "parcel" therefore seems *too* concrete).

This is precisely what I meant to recommend: "Parcel" would be a good replacement word for the Python-specific meaning of "distribution".  I'm sorry if I was ambiguous and created confusion.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20100110/8e793e98/attachment.htm>

From regebro at gmail.com  Sun Jan 10 11:54:39 2010
From: regebro at gmail.com (Lennart Regebro)
Date: Sun, 10 Jan 2010 11:54:39 +0100
Subject: [Distutils] [Catalog-sig] packaging terminology confusion
In-Reply-To: <49F3FD7D-00FF-48E0-88C8-7A753941BC15@twistedmatrix.com>
References: <4957f1ef1001070340y94da3cbgbc6dfe6c05028f3f@mail.gmail.com>
	<4B46AD73.4000902@v.loewis.de> <20100108103539.20bd564c@freewill>
	<4B47547F.5090303@pangalactic.us>
	<319e029f1001080829w4a140dedr48e0d4dce249caed@mail.gmail.com>
	<4957f1ef1001080900h52f271ccg45f71f376592db79@mail.gmail.com>
	<20100108174506.B2C473A4074@sparrow.telecommunity.com>
	<4957f1ef1001090713l1ca97cd0k8254e9ed3ae4e34e@mail.gmail.com>
	<20100109163905.4671C3A4074@sparrow.telecommunity.com>
	<49F3FD7D-00FF-48E0-88C8-7A753941BC15@twistedmatrix.com>
Message-ID: <319e029f1001100254x74494ba5jef6093eb30b45c89@mail.gmail.com>

On Sun, Jan 10, 2010 at 10:01, Glyph Lefkowitz <glyph at twistedmatrix.com> wrote:
> This is precisely what I meant to recommend: "Parcel" would be a good
> replacement word for the Python-specific meaning of "distribution". ?I'm
> sorry if I was ambiguous and created confusion.

I think it sounds too much like a python-specific word, like "egg".
People would be lead to believe that "parcels" meant a particular
format. It would be a great name for a python specific package format
though, but I think eggs have got the mindshare there already. :)

-- 
Lennart Regebro: Python, Zope, Plone, Grok
http://regebro.wordpress.com/
+33 661 58 14 64

From ben+python at benfinney.id.au  Sun Jan 10 12:40:49 2010
From: ben+python at benfinney.id.au (Ben Finney)
Date: Sun, 10 Jan 2010 22:40:49 +1100
Subject: [Distutils] [Catalog-sig] packaging terminology confusion
References: <4957f1ef1001070340y94da3cbgbc6dfe6c05028f3f@mail.gmail.com>
	<4B46AD73.4000902@v.loewis.de> <20100108103539.20bd564c@freewill>
	<4B47547F.5090303@pangalactic.us>
	<319e029f1001080829w4a140dedr48e0d4dce249caed@mail.gmail.com>
	<4957f1ef1001080900h52f271ccg45f71f376592db79@mail.gmail.com>
	<20100108174506.B2C473A4074@sparrow.telecommunity.com>
	<4957f1ef1001090713l1ca97cd0k8254e9ed3ae4e34e@mail.gmail.com>
	<20100109163905.4671C3A4074@sparrow.telecommunity.com>
	<49F3FD7D-00FF-48E0-88C8-7A753941BC15@twistedmatrix.com>
	<319e029f1001100254x74494ba5jef6093eb30b45c89@mail.gmail.com>
Message-ID: <871vhyur0e.fsf@benfinney.id.au>

Lennart Regebro <regebro at gmail.com> writes:

> On Sun, Jan 10, 2010 at 10:01, Glyph Lefkowitz <glyph at twistedmatrix.com> wrote:
> > This is precisely what I meant to recommend: "Parcel" would be a
> > good replacement word for the Python-specific meaning of
> > "distribution". ?I'm sorry if I was ambiguous and created confusion.
>
> I think it sounds too much like a python-specific word, like "egg".

Agreed.

At this point, people are just going to keep calling this entity a
?package?, consistent with the majority of other languages and systems
out there.

We'd have more chance, I think, of changing Python's concept ?namespace
that behaves like a module and can have sub-modules? ? currently called
?package? ? to a different word and encouraging adoption of that new
term.

Neither terminology change would be easy, but trying to change a raft of
other concepts to Python-specific terms seems less likely to succeed
than picking a new term for a concept that is *already* Python-specific.

-- 
 \     ?For every complex problem, there is a solution that is simple, |
  `\                               neat, and wrong.? ?Henry L. Mencken |
_o__)                                                                  |
Ben Finney


From ziade.tarek at gmail.com  Sun Jan 10 12:49:56 2010
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Sun, 10 Jan 2010 12:49:56 +0100
Subject: [Distutils] packaging terminology confusion
In-Reply-To: <871vhy7su0.fsf@wks.lan>
References: <4957f1ef1001070340y94da3cbgbc6dfe6c05028f3f@mail.gmail.com>
	<20100108174506.B2C473A4074@sparrow.telecommunity.com>
	<4957f1ef1001090713l1ca97cd0k8254e9ed3ae4e34e@mail.gmail.com>
	<20100109163905.4671C3A4074@sparrow.telecommunity.com>
	<4957f1ef1001091047i661d79c1tfeb379386d95989a@mail.gmail.com>
	<4957f1ef1001091051p6f700bb9i27c43b5143bcc907@mail.gmail.com>
	<87ljg784wc.fsf@wks.lan>
	<319e029f1001091148j3c6a929g6867a89efb5da776@mail.gmail.com>
	<65e0bb521001091504m43dd8ccctd3e41231033971c0@mail.gmail.com>
	<871vhy7su0.fsf@wks.lan>
Message-ID: <94bdd2611001100349y6963b051hf6ff986a4c848823@mail.gmail.com>

On Sun, Jan 10, 2010 at 12:37 AM, Suno Ano <suno.ano at sunoano.org> wrote:
> ?John> I would also add the common use of the term "distribution" to
> ?John> that glossary as well.
>
> Yes, true that, at http://python.org/download/ we have *distributions*
> to download.
>
> I figure the definition for *Installer* should then include that term
> too. To summarize, we now have the terms
>
> ?- package
> ?- parcel
> ?- project
> ?- release
> ?- installer
> ?- distribution
>
> Do others agree? Is something missing? Something wrong with that point
> of view?

I am not sure to understand what is the difference between "parcel"
and "distribution" in your list, because
the definition John gave doesn't really differ ("that big software
archive that you download, unpack, and install-")

From regebro at gmail.com  Sun Jan 10 12:52:21 2010
From: regebro at gmail.com (Lennart Regebro)
Date: Sun, 10 Jan 2010 12:52:21 +0100
Subject: [Distutils] [Catalog-sig] packaging terminology confusion
In-Reply-To: <871vhyur0e.fsf@benfinney.id.au>
References: <4957f1ef1001070340y94da3cbgbc6dfe6c05028f3f@mail.gmail.com>
	<4B47547F.5090303@pangalactic.us>
	<319e029f1001080829w4a140dedr48e0d4dce249caed@mail.gmail.com>
	<4957f1ef1001080900h52f271ccg45f71f376592db79@mail.gmail.com>
	<20100108174506.B2C473A4074@sparrow.telecommunity.com>
	<4957f1ef1001090713l1ca97cd0k8254e9ed3ae4e34e@mail.gmail.com>
	<20100109163905.4671C3A4074@sparrow.telecommunity.com>
	<49F3FD7D-00FF-48E0-88C8-7A753941BC15@twistedmatrix.com>
	<319e029f1001100254x74494ba5jef6093eb30b45c89@mail.gmail.com>
	<871vhyur0e.fsf@benfinney.id.au>
Message-ID: <319e029f1001100352i70ef807dueaf99dcf0493273@mail.gmail.com>

On Sun, Jan 10, 2010 at 12:40, Ben Finney <ben+python at benfinney.id.au> wrote:
> At this point, people are just going to keep calling this entity a
> ?package?, consistent with the majority of other languages and systems
> out there.

I'm not sure that's a problem. When you are talking about installation
and distribution, the distribution and the package are almost
identical.

> We'd have more chance, I think, of changing Python's concept ?namespace
> that behaves like a module and can have sub-modules? ? currently called
> ?package? ? to a different word and encouraging adoption of that new
> term.

I don't think it's realistic to change the name of one of the
fundamental concepts of Python. I sure as heck is not a question for
distutils-list. :-)

-- 
Lennart Regebro: Python, Zope, Plone, Grok
http://regebro.wordpress.com/
+33 661 58 14 64

From ziade.tarek at gmail.com  Sun Jan 10 12:53:45 2010
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Sun, 10 Jan 2010 12:53:45 +0100
Subject: [Distutils] [Catalog-sig] packaging terminology confusion
In-Reply-To: <871vhyur0e.fsf@benfinney.id.au>
References: <4957f1ef1001070340y94da3cbgbc6dfe6c05028f3f@mail.gmail.com>
	<4B47547F.5090303@pangalactic.us>
	<319e029f1001080829w4a140dedr48e0d4dce249caed@mail.gmail.com>
	<4957f1ef1001080900h52f271ccg45f71f376592db79@mail.gmail.com>
	<20100108174506.B2C473A4074@sparrow.telecommunity.com>
	<4957f1ef1001090713l1ca97cd0k8254e9ed3ae4e34e@mail.gmail.com>
	<20100109163905.4671C3A4074@sparrow.telecommunity.com>
	<49F3FD7D-00FF-48E0-88C8-7A753941BC15@twistedmatrix.com>
	<319e029f1001100254x74494ba5jef6093eb30b45c89@mail.gmail.com>
	<871vhyur0e.fsf@benfinney.id.au>
Message-ID: <94bdd2611001100353s41b5585w396bcfdb12986ae9@mail.gmail.com>

On Sun, Jan 10, 2010 at 12:40 PM, Ben Finney <ben+python at benfinney.id.au> wrote:
> Lennart Regebro <regebro at gmail.com> writes:
>
>> On Sun, Jan 10, 2010 at 10:01, Glyph Lefkowitz <glyph at twistedmatrix.com> wrote:
>> > This is precisely what I meant to recommend: "Parcel" would be a
>> > good replacement word for the Python-specific meaning of
>> > "distribution". ?I'm sorry if I was ambiguous and created confusion.
>>
>> I think it sounds too much like a python-specific word, like "egg".
>
> Agreed.
>
> At this point, people are just going to keep calling this entity a
> ?package?, consistent with the majority of other languages and systems
> out there.

Who is "people". AFAIK, most Python developers use the word "package"
for "python package"
and when they use the word "package" for "distribution", they will
stop doing it if they are told
that the proper word is "distribution" imho.

>
> We'd have more chance, I think, of changing Python's concept ?namespace
> that behaves like a module and can have sub-modules? ? currently called
> ?package? ? to a different word and encouraging adoption of that new
> term.

I think this is a way bigger change

Regards
Tarek
-- 
Tarek Ziad? | http://ziade.org

From bradallen137 at gmail.com  Sun Jan 10 16:24:48 2010
From: bradallen137 at gmail.com (Brad Allen)
Date: Sun, 10 Jan 2010 09:24:48 -0600
Subject: [Distutils] [Catalog-sig] packaging terminology confusion
In-Reply-To: <319e029f1001100254x74494ba5jef6093eb30b45c89@mail.gmail.com>
References: <4957f1ef1001070340y94da3cbgbc6dfe6c05028f3f@mail.gmail.com>
	<20100108103539.20bd564c@freewill> <4B47547F.5090303@pangalactic.us>
	<319e029f1001080829w4a140dedr48e0d4dce249caed@mail.gmail.com>
	<4957f1ef1001080900h52f271ccg45f71f376592db79@mail.gmail.com>
	<20100108174506.B2C473A4074@sparrow.telecommunity.com>
	<4957f1ef1001090713l1ca97cd0k8254e9ed3ae4e34e@mail.gmail.com>
	<20100109163905.4671C3A4074@sparrow.telecommunity.com>
	<49F3FD7D-00FF-48E0-88C8-7A753941BC15@twistedmatrix.com>
	<319e029f1001100254x74494ba5jef6093eb30b45c89@mail.gmail.com>
Message-ID: <4957f1ef1001100724l5d61c7ecob943d814d8b97d0a@mail.gmail.com>

On Sun, Jan 10, 2010 at 4:54 AM, Lennart Regebro <regebro at gmail.com> wrote:
> On Sun, Jan 10, 2010 at 10:01, Glyph Lefkowitz <glyph at twistedmatrix.com> wrote:
>> This is precisely what I meant to recommend: "Parcel" would be a good
>> replacement word for the Python-specific meaning of "distribution". ?I'm
>> sorry if I was ambiguous and created confusion.
>
> I think it sounds too much like a python-specific word, like "egg".
> People would be lead to believe that "parcels" meant a particular
> format. It would be a great name for a python specific package format
> though, but I think eggs have got the mindshare there already. :)

I had thought 'egg' was just another distribution format, an
alternative to tarball, etc. But I have heard people at my local user
group use it to mean 'module distribution'.

From bradallen137 at gmail.com  Sun Jan 10 17:01:40 2010
From: bradallen137 at gmail.com (Brad Allen)
Date: Sun, 10 Jan 2010 10:01:40 -0600
Subject: [Distutils] [Catalog-sig] packaging terminology confusion
In-Reply-To: <94bdd2611001100353s41b5585w396bcfdb12986ae9@mail.gmail.com>
References: <4957f1ef1001070340y94da3cbgbc6dfe6c05028f3f@mail.gmail.com>
	<319e029f1001080829w4a140dedr48e0d4dce249caed@mail.gmail.com>
	<4957f1ef1001080900h52f271ccg45f71f376592db79@mail.gmail.com>
	<20100108174506.B2C473A4074@sparrow.telecommunity.com>
	<4957f1ef1001090713l1ca97cd0k8254e9ed3ae4e34e@mail.gmail.com>
	<20100109163905.4671C3A4074@sparrow.telecommunity.com>
	<49F3FD7D-00FF-48E0-88C8-7A753941BC15@twistedmatrix.com>
	<319e029f1001100254x74494ba5jef6093eb30b45c89@mail.gmail.com>
	<871vhyur0e.fsf@benfinney.id.au>
	<94bdd2611001100353s41b5585w396bcfdb12986ae9@mail.gmail.com>
Message-ID: <4957f1ef1001100801r5162231cg7be9192547b1e14c@mail.gmail.com>

On Sun, Jan 10, 2010 at 5:53 AM, Tarek Ziad? <ziade.tarek at gmail.com> wrote:
> On Sun, Jan 10, 2010 at 12:40 PM, Ben Finney <ben+python at benfinney.id.au> wrote:
>> Lennart Regebro <regebro at gmail.com> writes:
>>
>>> On Sun, Jan 10, 2010 at 10:01, Glyph Lefkowitz <glyph at twistedmatrix.com> wrote:
>>> > This is precisely what I meant to recommend: "Parcel" would be a
>>> > good replacement word for the Python-specific meaning of
>>> > "distribution". ?I'm sorry if I was ambiguous and created confusion.
>>>
>>> I think it sounds too much like a python-specific word, like "egg".
>>
>> Agreed.
>>
>> At this point, people are just going to keep calling this entity a
>> ?package?, consistent with the majority of other languages and systems
>> out there.
>
> Who is "people". AFAIK, most Python developers use the word "package"
> for "python package"
> and when they use the word "package" for "distribution", they will
> stop doing it if they are told
> that the proper word is "distribution" imho.

Maybe that will work...if we go that route, can we shorten 'module
distribution' to just 'distribution' in the distutils terminology
docs? That would help support the general usage.

We would also need to change the PyPI web pages which uses the word
'package' a lot. I see it in a lot of the README files published
through PyPI as well.

>> We'd have more chance, I think, of changing Python's concept ?namespace
>> that behaves like a module and can have sub-modules? ? currently called
>> ?package? ? to a different word and encouraging adoption of that new
>> term.
>
> I think this is a way bigger change

Yes, it's a big change but common usage is a strong tailwind which
could make it easier. It could start with a PEP and a survey link sent
to python-announce. Personally I strongly prefer the word 'package'
the way it is used today in the PyPI user interface. Using the word
'distribution' all over that page just doesn't seem right...


For future reference, here is what the PyPI front page shows today:
--------------------------------------------------
The Python Package Index is a repository of software for the Python
programming language. There are currently 8639 packages here. To
contact the PyPI admins, please use the Get help or Bug reports links.

To submit a package use "python setup.py upload" and to use a package
from this index either "pip install package" or download, unpack and
"python setup.py install" it.

    * Browse the tree of packages
    * Submit package information (note that you must register to submit)

There now is an RPM repository that provides RPMs for most of the
packages available here on PyPI.

Updated	Package	Description
2010-01-10 	PyFFI 2.1.0 	Processing block structured binary files.
2010-01-10 	bdist_nsi 0.1.1 	Create NSIS windows installers for Python modules.
2010-01-10 	zope.app.intid 3.7.1 	ZMI views for Integer Id Utility
2010-01-10 	Clip2Zeus 0.5 	Monitor your clipboard for URLs and
automatically shorten them using 2Zeus
2010-01-10 	bluebream 0.1.7 	The Zope Web Framework
2010-01-10 	testrepository 0.0.2 	A repository of test results.

From jmg3000 at gmail.com  Sun Jan 10 17:31:19 2010
From: jmg3000 at gmail.com (John Gabriele)
Date: Sun, 10 Jan 2010 11:31:19 -0500
Subject: [Distutils] [Catalog-sig] packaging terminology confusion
In-Reply-To: <94bdd2611001100353s41b5585w396bcfdb12986ae9@mail.gmail.com>
References: <4957f1ef1001070340y94da3cbgbc6dfe6c05028f3f@mail.gmail.com>
	<319e029f1001080829w4a140dedr48e0d4dce249caed@mail.gmail.com>
	<4957f1ef1001080900h52f271ccg45f71f376592db79@mail.gmail.com>
	<20100108174506.B2C473A4074@sparrow.telecommunity.com>
	<4957f1ef1001090713l1ca97cd0k8254e9ed3ae4e34e@mail.gmail.com>
	<20100109163905.4671C3A4074@sparrow.telecommunity.com>
	<49F3FD7D-00FF-48E0-88C8-7A753941BC15@twistedmatrix.com>
	<319e029f1001100254x74494ba5jef6093eb30b45c89@mail.gmail.com>
	<871vhyur0e.fsf@benfinney.id.au>
	<94bdd2611001100353s41b5585w396bcfdb12986ae9@mail.gmail.com>
Message-ID: <65e0bb521001100831y5e64efdcpfe540c0f5b593a2b@mail.gmail.com>

On Sun, Jan 10, 2010 at 6:53 AM, Tarek Ziad? <ziade.tarek at gmail.com> wrote:
> On Sun, Jan 10, 2010 at 12:40 PM, Ben Finney <ben+python at benfinney.id.au> wrote:
>
>> At this point, people are just going to keep calling this entity a
>> ?package?, consistent with the majority of other languages and systems
>> out there.
>
> Who is "people". AFAIK, most Python developers use the word "package"
> for "python package"
> and when they use the word "package" for "distribution", they will
> stop doing it if they are told
> that the proper word is "distribution" imho.

Well, I notice that the entire [packaging chapter of
diveintopython3](http://diveintopython3.org/packaging.html) refers to
distributions as "packages".

And it's *very* common for new users to be sent to
diveintopython/diveintopython3 when learning the language.

---John

From regebro at gmail.com  Sun Jan 10 17:32:30 2010
From: regebro at gmail.com (Lennart Regebro)
Date: Sun, 10 Jan 2010 17:32:30 +0100
Subject: [Distutils] [Catalog-sig] packaging terminology confusion
In-Reply-To: <4957f1ef1001100724l5d61c7ecob943d814d8b97d0a@mail.gmail.com>
References: <4957f1ef1001070340y94da3cbgbc6dfe6c05028f3f@mail.gmail.com>
	<4B47547F.5090303@pangalactic.us>
	<319e029f1001080829w4a140dedr48e0d4dce249caed@mail.gmail.com>
	<4957f1ef1001080900h52f271ccg45f71f376592db79@mail.gmail.com>
	<20100108174506.B2C473A4074@sparrow.telecommunity.com>
	<4957f1ef1001090713l1ca97cd0k8254e9ed3ae4e34e@mail.gmail.com>
	<20100109163905.4671C3A4074@sparrow.telecommunity.com>
	<49F3FD7D-00FF-48E0-88C8-7A753941BC15@twistedmatrix.com>
	<319e029f1001100254x74494ba5jef6093eb30b45c89@mail.gmail.com>
	<4957f1ef1001100724l5d61c7ecob943d814d8b97d0a@mail.gmail.com>
Message-ID: <319e029f1001100832q674488d4n73d6ca8ce0f60c05@mail.gmail.com>

On Sun, Jan 10, 2010 at 16:24, Brad Allen <bradallen137 at gmail.com> wrote:
> I had thought 'egg' was just another distribution format, an
> alternative to tarball, etc. But I have heard people at my local user
> group use it to mean 'module distribution'.

Yeah, there is some confusion there. As I understand it, 'Egg' isn't
even a distribution format, and egg is a package that has extra
information. There is also a distribution format, .egg, but a tarball
that includes a .egg-info directory is an egg. A tarball that doesn't,
but has a setup.py, is not an egg, but may be used to make it one.

Or?

That is terminology that may need discussing.
-- 
Lennart Regebro: Python, Zope, Plone, Grok
http://regebro.wordpress.com/
+33 661 58 14 64

From pje at telecommunity.com  Sun Jan 10 18:38:42 2010
From: pje at telecommunity.com (P.J. Eby)
Date: Sun, 10 Jan 2010 12:38:42 -0500
Subject: [Distutils] [Catalog-sig] packaging terminology confusion
In-Reply-To: <319e029f1001100832q674488d4n73d6ca8ce0f60c05@mail.gmail.co
 m>
References: <4957f1ef1001070340y94da3cbgbc6dfe6c05028f3f@mail.gmail.com>
	<4B47547F.5090303@pangalactic.us>
	<319e029f1001080829w4a140dedr48e0d4dce249caed@mail.gmail.com>
	<4957f1ef1001080900h52f271ccg45f71f376592db79@mail.gmail.com>
	<20100108174506.B2C473A4074@sparrow.telecommunity.com>
	<4957f1ef1001090713l1ca97cd0k8254e9ed3ae4e34e@mail.gmail.com>
	<20100109163905.4671C3A4074@sparrow.telecommunity.com>
	<49F3FD7D-00FF-48E0-88C8-7A753941BC15@twistedmatrix.com>
	<319e029f1001100254x74494ba5jef6093eb30b45c89@mail.gmail.com>
	<4957f1ef1001100724l5d61c7ecob943d814d8b97d0a@mail.gmail.com>
	<319e029f1001100832q674488d4n73d6ca8ce0f60c05@mail.gmail.com>
Message-ID: <20100110173856.AF1A33A4065@sparrow.telecommunity.com>

At 05:32 PM 1/10/2010 +0100, Lennart Regebro wrote:
>On Sun, Jan 10, 2010 at 16:24, Brad Allen <bradallen137 at gmail.com> wrote:
> > I had thought 'egg' was just another distribution format, an
> > alternative to tarball, etc. But I have heard people at my local user
> > group use it to mean 'module distribution'.
>
>Yeah, there is some confusion there. As I understand it, 'Egg' isn't
>even a distribution format,

Right - it's an importable (i.e. addable-to-sys.path) binary 
distribution with project release metadata attached.  .egg files, 
.egg directories, and "flat" installations with associated .egg-info 
directories are all "eggs".

(Also, since Python 2.5+ distutils generate .egg-info files, all 
distutils-installed module distributions from Python 2.5 on are 
technically eggs.)


>and egg is a package that has extra
>information.

Actually, it's a project release with extra information - packages 
may or may not be involved, since an egg may contain only a script or 
some modules.


>There is also a distribution format, .egg, but a tarball
>that includes a .egg-info directory is an egg.

Technically, the tarball *contains* an egg, but is not itself an egg, 
since it cannot be added to sys.path (at least not without using some 
PEP 302 and pkg_resources hooks that nobody has actually used yet, AFAIK).


>  A tarball that doesn't,
>but has a setup.py, is not an egg, but may be used to make it one.

Actually, if the tarball was generated by setuptools, then its 
contents may also be an egg (since as part of the sdist process, an 
.egg-info directory is generated.


From ziade.tarek at gmail.com  Sun Jan 10 18:46:44 2010
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Sun, 10 Jan 2010 18:46:44 +0100
Subject: [Distutils] [Catalog-sig] packaging terminology confusion
In-Reply-To: <4957f1ef1001100801r5162231cg7be9192547b1e14c@mail.gmail.com>
References: <4957f1ef1001070340y94da3cbgbc6dfe6c05028f3f@mail.gmail.com>
	<4957f1ef1001080900h52f271ccg45f71f376592db79@mail.gmail.com>
	<20100108174506.B2C473A4074@sparrow.telecommunity.com>
	<4957f1ef1001090713l1ca97cd0k8254e9ed3ae4e34e@mail.gmail.com>
	<20100109163905.4671C3A4074@sparrow.telecommunity.com>
	<49F3FD7D-00FF-48E0-88C8-7A753941BC15@twistedmatrix.com>
	<319e029f1001100254x74494ba5jef6093eb30b45c89@mail.gmail.com>
	<871vhyur0e.fsf@benfinney.id.au>
	<94bdd2611001100353s41b5585w396bcfdb12986ae9@mail.gmail.com>
	<4957f1ef1001100801r5162231cg7be9192547b1e14c@mail.gmail.com>
Message-ID: <94bdd2611001100946h1d5bd1c8o71eb842191158a2a@mail.gmail.com>

On Sun, Jan 10, 2010 at 5:01 PM, Brad Allen <bradallen137 at gmail.com> wrote:
> On Sun, Jan 10, 2010 at 5:53 AM, Tarek Ziad? <ziade.tarek at gmail.com> wrote:
>> On Sun, Jan 10, 2010 at 12:40 PM, Ben Finney <ben+python at benfinney.id.au> wrote:
>>> Lennart Regebro <regebro at gmail.com> writes:
>>>
>>>> On Sun, Jan 10, 2010 at 10:01, Glyph Lefkowitz <glyph at twistedmatrix.com> wrote:
>>>> > This is precisely what I meant to recommend: "Parcel" would be a
>>>> > good replacement word for the Python-specific meaning of
>>>> > "distribution". ?I'm sorry if I was ambiguous and created confusion.
>>>>
>>>> I think it sounds too much like a python-specific word, like "egg".
>>>
>>> Agreed.
>>>
>>> At this point, people are just going to keep calling this entity a
>>> ?package?, consistent with the majority of other languages and systems
>>> out there.
>>
>> Who is "people". AFAIK, most Python developers use the word "package"
>> for "python package"
>> and when they use the word "package" for "distribution", they will
>> stop doing it if they are told
>> that the proper word is "distribution" imho.
>
> Maybe that will work...if we go that route, can we shorten 'module
> distribution' to just 'distribution' in the distutils terminology
> docs? That would help support the general usage.
>
> We would also need to change the PyPI web pages which uses the word
> 'package' a lot. I see it in a lot of the README files published
> through PyPI as well.
>
>>> We'd have more chance, I think, of changing Python's concept ?namespace
>>> that behaves like a module and can have sub-modules? ? currently called
>>> ?package? ? to a different word and encouraging adoption of that new
>>> term.
>>
>> I think this is a way bigger change
>
> Yes, it's a big change but common usage is a strong tailwind which
> could make it easier. It could start with a PEP and a survey link sent
> to python-announce. Personally I strongly prefer the word 'package'
> the way it is used today in the PyPI user interface. Using the word
> 'distribution' all over that page just doesn't seem right...

I think we just need to agree on a list of definition and update these
two pages:

- http://docs.python.org/dev/distutils/introduction.html#general-python-terminology
- http://docs.python.org/dev/distutils/introduction.html#distutils-specific-terminology

Rafael add the latest version here :
http://wiki.python.org/moin/Distutils/Terminology  (with improvements
I am going to coming)

Maybe what you could do is propose your own terminology under this one
in the wiki page,
I'll do the same (mainly by copying Tres' definition)

And we can try to considate several proposals and work on a consensus

>
> For future reference, here is what the PyPI front page shows today:

(MvL said he would change "package" to "project" without problem, so
I don't think that we need to decide the best term using that page.

Regards,

Tarek
-- 
Tarek Ziad? | http://ziade.org

From pachi at rvburke.com  Sun Jan 10 19:50:48 2010
From: pachi at rvburke.com (Rafael Villar Burke (Pachi))
Date: Sun, 10 Jan 2010 19:50:48 +0100
Subject: [Distutils] [Catalog-sig] packaging terminology confusion
In-Reply-To: <94bdd2611001100946h1d5bd1c8o71eb842191158a2a@mail.gmail.com>
References: <4957f1ef1001070340y94da3cbgbc6dfe6c05028f3f@mail.gmail.com>	<4957f1ef1001080900h52f271ccg45f71f376592db79@mail.gmail.com>	<20100108174506.B2C473A4074@sparrow.telecommunity.com>	<4957f1ef1001090713l1ca97cd0k8254e9ed3ae4e34e@mail.gmail.com>	<20100109163905.4671C3A4074@sparrow.telecommunity.com>	<49F3FD7D-00FF-48E0-88C8-7A753941BC15@twistedmatrix.com>	<319e029f1001100254x74494ba5jef6093eb30b45c89@mail.gmail.com>	<871vhyur0e.fsf@benfinney.id.au>	<94bdd2611001100353s41b5585w396bcfdb12986ae9@mail.gmail.com>	<4957f1ef1001100801r5162231cg7be9192547b1e14c@mail.gmail.com>
	<94bdd2611001100946h1d5bd1c8o71eb842191158a2a@mail.gmail.com>
Message-ID: <4B4A2188.3050609@rvburke.com>

On 10/01/2010 18:46, Tarek Ziad? wrote:
> On Sun, Jan 10, 2010 at 5:01 PM, Brad Allen<bradallen137 at gmail.com>  wrote:
>    
>> Yes, it's a big change but common usage is a strong tailwind which
>> could make it easier. It could start with a PEP and a survey link sent
>> to python-announce. Personally I strongly prefer the word 'package'
>> the way it is used today in the PyPI user interface. Using the word
>> 'distribution' all over that page just doesn't seem right...
>>      
> I think we just need to agree on a list of definition and update these
> two pages:
>
> - http://docs.python.org/dev/distutils/introduction.html#general-python-terminology
> - http://docs.python.org/dev/distutils/introduction.html#distutils-specific-terminology
>
> Rafael add the latest version here :
> http://wiki.python.org/moin/Distutils/Terminology  (with improvements
> I am going to coming)
>
> Maybe what you could do is propose your own terminology under this one
> in the wiki page,
> I'll do the same (mainly by copying Tres' definition)
I'm joining the list now and will try to help, so, hi all!

AFAICT, once the release and project terms are added to the list of 
definitions the terminology confusion revolves around the following options:

1) make package mean distribution and replace the current package term 
with a different one.
2) don allow package as synonymous of distribution and come with a nicer 
term than distribution with the hope that it will be more widely used 
than package and distribution.
3) somehow make legal the commonly-used-in-pactice but inaccurate 
package term as a synonymous of distribution.

I find 1 and 2 not very practical, as they try to fight a common and 
intuitive use of the a widespread word like "package" (excepting the 
accurate use made by people familiar enough with distutils which already 
don't have any problem with the existing terms). Also, the alternative 
terms have, IMHO, the drawback of not being as obvious as "package" in 
their meaning for indoeuropean language speakers (and probably for 
english speakers too).

I feel that part of the confusion about "packages" and its inaccurate 
use in informal language happens because packaging intuitively reflects 
both what we do with modules in proper packages and what with do with 
projects or software in what's called a distribution, by grouping 
separate content. The packaging word also has the advantage of alluding 
to an object you can manipulate (like in giving it to others), while 
distribution, AFAICT, hasn't much use as a common name (to denote an 
object) apart from the too technical "Linux distributions" use.

That's why I think 1) is easier and find very compelling John 
Gabrielle's idea of qualifying the terms "package" as "module package" 
and "(module) distribution" as "distribution package". These point to 
the two levels of packaging or grouping used, one for namespacing or 
grouping code and other for distribution or grouping software components 
for distribution.

The expanded terms would also allow the current formal terms as 
abbreviations (package vs distribution) and a more informal and general 
term (package) that could be further qualified when additional context 
for more precision is needed.

In any case, the problem with PyPI meaning "Python Project Index" or 
staying as it is now if package is "distribution package" would then be 
solved too.

Regards,

Rafael Villar Burke

From bradallen137 at gmail.com  Sun Jan 10 19:59:27 2010
From: bradallen137 at gmail.com (Brad Allen)
Date: Sun, 10 Jan 2010 12:59:27 -0600
Subject: [Distutils] [Catalog-sig] packaging terminology confusion
In-Reply-To: <4B4A2188.3050609@rvburke.com>
References: <4957f1ef1001070340y94da3cbgbc6dfe6c05028f3f@mail.gmail.com>
	<4957f1ef1001090713l1ca97cd0k8254e9ed3ae4e34e@mail.gmail.com>
	<20100109163905.4671C3A4074@sparrow.telecommunity.com>
	<49F3FD7D-00FF-48E0-88C8-7A753941BC15@twistedmatrix.com>
	<319e029f1001100254x74494ba5jef6093eb30b45c89@mail.gmail.com>
	<871vhyur0e.fsf@benfinney.id.au>
	<94bdd2611001100353s41b5585w396bcfdb12986ae9@mail.gmail.com>
	<4957f1ef1001100801r5162231cg7be9192547b1e14c@mail.gmail.com>
	<94bdd2611001100946h1d5bd1c8o71eb842191158a2a@mail.gmail.com>
	<4B4A2188.3050609@rvburke.com>
Message-ID: <4957f1ef1001101059t477ca58eg2a8faa38563a1195@mail.gmail.com>

On Sun, Jan 10, 2010 at 12:50 PM, Rafael Villar Burke (Pachi)
<pachi at rvburke.com> wrote:

> That's why I think 1) is easier and find very compelling John Gabrielle's
> idea of qualifying the terms "package" as "module package" and "(module)
> distribution" as "distribution package". These point to the two levels of
> packaging or grouping used, one for namespacing or grouping code and other
> for distribution or grouping software components for distribution.

+1

This idea is starting to seem like a practical solution that won't
damage the future readability of old documentation and archived
mailing list discussions.

From ben+python at benfinney.id.au  Sun Jan 10 22:02:00 2010
From: ben+python at benfinney.id.au (Ben Finney)
Date: Mon, 11 Jan 2010 08:02:00 +1100
Subject: [Distutils] [Catalog-sig] packaging terminology confusion
References: <4957f1ef1001070340y94da3cbgbc6dfe6c05028f3f@mail.gmail.com>
	<4B47547F.5090303@pangalactic.us>
	<319e029f1001080829w4a140dedr48e0d4dce249caed@mail.gmail.com>
	<4957f1ef1001080900h52f271ccg45f71f376592db79@mail.gmail.com>
	<20100108174506.B2C473A4074@sparrow.telecommunity.com>
	<4957f1ef1001090713l1ca97cd0k8254e9ed3ae4e34e@mail.gmail.com>
	<20100109163905.4671C3A4074@sparrow.telecommunity.com>
	<49F3FD7D-00FF-48E0-88C8-7A753941BC15@twistedmatrix.com>
	<319e029f1001100254x74494ba5jef6093eb30b45c89@mail.gmail.com>
	<871vhyur0e.fsf@benfinney.id.au>
	<319e029f1001100352i70ef807dueaf99dcf0493273@mail.gmail.com>
Message-ID: <87wrzpu113.fsf@benfinney.id.au>

Lennart Regebro <regebro at gmail.com> writes:

> On Sun, Jan 10, 2010 at 12:40, Ben Finney <ben+python at benfinney.id.au> wrote:
> > At this point, people are just going to keep calling this entity a
> > ?package?, consistent with the majority of other languages and
> > systems out there.
>
> I'm not sure that's a problem. When you are talking about installation
> and distribution, the distribution and the package are almost
> identical.

I can't understand this because of the ambiguity of the term ?package?.

You might be saying something tautologically true: When the terms
?package? and ?distribution? are used to refer to the same thing, their
referents are identical. Well yes, of course.

The other alternative seems to be that you're saying something we know
to be false: it has already been demonstrated that an entity that Python
terminology calls a ?distribution? can contain zero, one, or multiple
entities that Python calls ?package?.

> > We'd have more chance, I think, of changing Python's concept
> > ?namespace that behaves like a module and can have sub-modules? ?
> > currently called ?package? ? to a different word and encouraging
> > adoption of that new term.
>
> I don't think it's realistic to change the name of one of the
> fundamental concepts of Python.

It's an option to be considered, I think. Especially since the
alternative proposal seems to be to change the name of one of the
fundamental concepts already in established use *outside* Python.

> I sure as heck is not a question for distutils-list. :-)

Probably not.

-- 
 \         ?I'm not a bad guy! I work hard, and I love my kids. So why |
  `\      should I spend half my Sunday hearing about how I'm going to |
_o__)                                            Hell?? ?Homer Simpson |
Ben Finney


From ben+python at benfinney.id.au  Sun Jan 10 22:05:42 2010
From: ben+python at benfinney.id.au (Ben Finney)
Date: Mon, 11 Jan 2010 08:05:42 +1100
Subject: [Distutils] [Catalog-sig] packaging terminology confusion
References: <4957f1ef1001070340y94da3cbgbc6dfe6c05028f3f@mail.gmail.com>
	<4B47547F.5090303@pangalactic.us>
	<319e029f1001080829w4a140dedr48e0d4dce249caed@mail.gmail.com>
	<4957f1ef1001080900h52f271ccg45f71f376592db79@mail.gmail.com>
	<20100108174506.B2C473A4074@sparrow.telecommunity.com>
	<4957f1ef1001090713l1ca97cd0k8254e9ed3ae4e34e@mail.gmail.com>
	<20100109163905.4671C3A4074@sparrow.telecommunity.com>
	<49F3FD7D-00FF-48E0-88C8-7A753941BC15@twistedmatrix.com>
	<319e029f1001100254x74494ba5jef6093eb30b45c89@mail.gmail.com>
	<871vhyur0e.fsf@benfinney.id.au>
	<94bdd2611001100353s41b5585w396bcfdb12986ae9@mail.gmail.com>
Message-ID: <87skadu0ux.fsf@benfinney.id.au>

Tarek Ziad? <ziade.tarek at gmail.com> writes:

> On Sun, Jan 10, 2010 at 12:40 PM, Ben Finney <ben+python at benfinney.id.au> wrote:
> > At this point, people are just going to keep calling this entity a
> > ?package?, consistent with the majority of other languages and
> > systems out there.
>
> Who is "people". AFAIK, most Python developers use the word "package"
> for "python package" and when they use the word "package" for
> "distribution", they will stop doing it if they are told that the
> proper word is "distribution" imho.

That's exactly opposite to my experience. The established term for this
concept is ?package?, and that will remain true and continue to be
reinforced by the general programming culture.

Expecting programmers to use a Python-specific term, when there's
already a wider-use term that fits exactly the same concept, is
foolhardy in my opinion.

-- 
 \       ?I cannot be angry at God, in whom I do not believe.? ?Simone |
  `\                                                       De Beauvoir |
_o__)                                                                  |
Ben Finney


From regebro at gmail.com  Sun Jan 10 22:14:33 2010
From: regebro at gmail.com (Lennart Regebro)
Date: Sun, 10 Jan 2010 22:14:33 +0100
Subject: [Distutils] [Catalog-sig] packaging terminology confusion
In-Reply-To: <20100110173856.AF1A33A4065@sparrow.telecommunity.com>
References: <4957f1ef1001070340y94da3cbgbc6dfe6c05028f3f@mail.gmail.com>
	<4957f1ef1001080900h52f271ccg45f71f376592db79@mail.gmail.com>
	<20100108174506.B2C473A4074@sparrow.telecommunity.com>
	<4957f1ef1001090713l1ca97cd0k8254e9ed3ae4e34e@mail.gmail.com>
	<20100109163905.4671C3A4074@sparrow.telecommunity.com>
	<49F3FD7D-00FF-48E0-88C8-7A753941BC15@twistedmatrix.com>
	<319e029f1001100254x74494ba5jef6093eb30b45c89@mail.gmail.com>
	<4957f1ef1001100724l5d61c7ecob943d814d8b97d0a@mail.gmail.com>
	<319e029f1001100832q674488d4n73d6ca8ce0f60c05@mail.gmail.com>
	<20100110173856.AF1A33A4065@sparrow.telecommunity.com>
Message-ID: <319e029f1001101314w18427e41u6306d6c8dc7241bd@mail.gmail.com>

On Sun, Jan 10, 2010 at 18:38, P.J. Eby <pje at telecommunity.com> wrote:
> (Also, since Python 2.5+ distutils generate .egg-info files, all
> distutils-installed module distributions from Python 2.5 on are technically
> eggs.)

Aha... Stuck in Plone-land, I'm still mostly on 2.4. :-)
That means that calling distributions "eggs" are technically
incorrect, but mostly not in a practically significant way. That's
good.

-- 
Lennart Regebro: Python, Zope, Plone, Grok
http://regebro.wordpress.com/
+33 661 58 14 64

From regebro at gmail.com  Sun Jan 10 22:19:54 2010
From: regebro at gmail.com (Lennart Regebro)
Date: Sun, 10 Jan 2010 22:19:54 +0100
Subject: [Distutils] [Catalog-sig] packaging terminology confusion
In-Reply-To: <87wrzpu113.fsf@benfinney.id.au>
References: <4957f1ef1001070340y94da3cbgbc6dfe6c05028f3f@mail.gmail.com>
	<4957f1ef1001080900h52f271ccg45f71f376592db79@mail.gmail.com>
	<20100108174506.B2C473A4074@sparrow.telecommunity.com>
	<4957f1ef1001090713l1ca97cd0k8254e9ed3ae4e34e@mail.gmail.com>
	<20100109163905.4671C3A4074@sparrow.telecommunity.com>
	<49F3FD7D-00FF-48E0-88C8-7A753941BC15@twistedmatrix.com>
	<319e029f1001100254x74494ba5jef6093eb30b45c89@mail.gmail.com>
	<871vhyur0e.fsf@benfinney.id.au>
	<319e029f1001100352i70ef807dueaf99dcf0493273@mail.gmail.com>
	<87wrzpu113.fsf@benfinney.id.au>
Message-ID: <319e029f1001101319h6ed7f2aayc8125aff500a45f8@mail.gmail.com>

On Sun, Jan 10, 2010 at 22:02, Ben Finney <ben+python at benfinney.id.au> wrote:
> You might be saying something tautologically true: When the terms
> ?package? and ?distribution? are used to refer to the same thing, their
> referents are identical. Well yes, of course.

No, what I'm saying is that each distribution typically contains a
package, and that when you therefore call distributions "packages" you
generally do not add any practical confusion. If you say "I need to
install this package" it may technically be unclear if you mean the
package "foo.bar" or the distribution "foo.bar-3.6.tgz", but that
difference is not in that case significant. Installing the
distribution and installing the package is in that case the same
thing.

-- 
Lennart Regebro: Python, Zope, Plone, Grok
http://regebro.wordpress.com/
+33 661 58 14 64

From david.lyon at preisshare.net  Mon Jan 11 01:20:54 2010
From: david.lyon at preisshare.net (David Lyon)
Date: Mon, 11 Jan 2010 11:20:54 +1100 (EST)
Subject: [Distutils] packaging terminology confusion
In-Reply-To: <94bdd2611001100349y6963b051hf6ff986a4c848823@mail.gmail.com>
References: <4957f1ef1001070340y94da3cbgbc6dfe6c05028f3f@mail.gmail.com>
	<20100108174506.B2C473A4074@sparrow.telecommunity.com>
	<4957f1ef1001090713l1ca97cd0k8254e9ed3ae4e34e@mail.gmail.com>
	<20100109163905.4671C3A4074@sparrow.telecommunity.com>
	<4957f1ef1001091047i661d79c1tfeb379386d95989a@mail.gmail.com>
	<4957f1ef1001091051p6f700bb9i27c43b5143bcc907@mail.gmail.com>
	<87ljg784wc.fsf@wks.lan>
	<319e029f1001091148j3c6a929g6867a89efb5da776@mail.gmail.com>
	<65e0bb521001091504m43dd8ccctd3e41231033971c0@mail.gmail.com>
	<871vhy7su0.fsf@wks.lan>
	<94bdd2611001100349y6963b051hf6ff986a4c848823@mail.gmail.com>
Message-ID: <3176.218.214.45.58.1263169254.squirrel@syd-srv02.ezyreg.com>

> On Sun, Jan 10, 2010 at 12:37 AM, Suno Ano <suno.ano at sunoano.org> wrote:
>> ?John> I would also add the common use of the term "distribution" to
>> ?John> that glossary as well.
>>
>> Yes, true that, at http://python.org/download/ we have *distributions*
>> to download.
>>
>> I figure the definition for *Installer* should then include that term
>> too. To summarize, we now have the terms
>>
>> ?- package
>> ?- parcel
>> ?- project
>> ?- release
>> ?- installer
>> ?- distribution
>>
>> Do others agree? Is something missing? Something wrong with that point
>> of view?
>
> I am not sure to understand what is the difference between "parcel"
> and "distribution" in your list, because
> the definition John gave doesn't really differ ("that big software
> archive that you download, unpack, and install-")

Hi Tarek,

I think what's being said here is that in the software
world the word "distribution", is already taken.

For example, a "python distribution" refers to the language
interpreter. A version of the python interpreter made to
run on a particular platform.

It is well accepted terminology already.

Perphaps, with Distribute, you're trying to have us rename
what we know as a package to be now known as distribution.
As a way to build a sort of loyalty to the 'Distribute'
package.

There are ways to accomplish that.. but not this way.

The problem is that using 'distribution' to describe
'package' generates confusion because 'distribution'
already has a an accepted meaning across existing
programming languages.

I think that is pretty much the point that's being
made. That 'distribution' is currently associated with
a language distribution.

As far as users were concerned, .EGGs are the best.

Since you have forked setuptools, it would make more
sense to work on the .egg format to bring this up
to a more modern standing.

To me, this would be a much more constructive way
to help clean up the packaging world than to introduce
more changes to the terminology. I'd even be happy
to help there. I think .EGG is great for packaging
(so simple a concept) but is undermined by some
technical (legacy) issues.

David








From david.lyon at preisshare.net  Mon Jan 11 01:57:07 2010
From: david.lyon at preisshare.net (David Lyon)
Date: Mon, 11 Jan 2010 11:57:07 +1100 (EST)
Subject: [Distutils] [Catalog-sig]  packaging terminology confusion
In-Reply-To: <723929E9-9814-4005-9025-4F38355DB5E7@twistedmatrix.com>
References: <4957f1ef1001070340y94da3cbgbc6dfe6c05028f3f@mail.gmail.com>
	<20100107164433.662DE3A4074@sparrow.telecommunity.com>
	<4B464207.3030507@v.loewis.de>
	<20100107204102.D121C3A4074@sparrow.telecommunity.com>
	<4957f1ef1001071329m2de42256k31581cf2c6d0a1e0@mail.gmail.com>
	<94bdd2611001071339g15942eb3rcf00dcb8ddd4ee5e@mail.gmail.com>
	<4B46576F.7070309@egenix.com>
	<4957f1ef1001071357y382db993qffaee3b5ba2277e2@mail.gmail.com>
	<4B465C5F.7030609@egenix.com>
	<94bdd2611001071422p56182196mb974e747a0adecd2@mail.gmail.com>
	<65e0bb521001071943n7bbf739au3f9c7fc9175c6d01@mail.gmail.com>
	<723929E9-9814-4005-9025-4F38355DB5E7@twistedmatrix.com>
Message-ID: <3282.218.214.45.58.1263171427.squirrel@syd-srv02.ezyreg.com>


Hi Glyph,

> It sure would be nice if we could use a made-up word like "eggs" to refer
> to these things.  Too bad that's taken too :-\.

Yes.

"eggs" is the best name anybody could hope for to describe a package. It
already has general acceptance to a large degree amongst users (despite
it's faults).

Even Tarek has adopted it by forking setuptools. Tarek has complete say on
the direction of the .EGG

What needs to be done is for a decision to occur to either kill or revive
the "egg" in 2010.

Let's either fix them, or kill them. Fixing the "egg" means that Tarek has
to "evolve" Distribute. Which is well within his power. Killing them means
taking the egg references out of existing peps and packages and pypi and
starting again. That's also possible.

As a regular developer, I'd call for a "L'Oeuf incredible". Excuse my bad
french. A new egg to replace all the bad old eggs.

We need more simplicity in packaging in python..

"eggs" are cool. They're simple. They're what users want. They're what
pypi needs.

I just don't know why it is that there is such a big desire in python-core
to chuck out the fun and simple and try to replace it with complicated and
confusing. It's so *not* monty python..

If the eggs are going to be thrown out... chuck those forkers out. But I
think it would be a big mistake.

David







From david.lyon at preisshare.net  Mon Jan 11 02:35:41 2010
From: david.lyon at preisshare.net (David Lyon)
Date: Mon, 11 Jan 2010 12:35:41 +1100 (EST)
Subject: [Distutils] Finishing PEP 345
In-Reply-To: <4B334626.6040505@v.loewis.de>
References: <94bdd2610912180641i6df1a26co9c3ff34aba034982@mail.gmail.com>
	<4B301D54.6050109@v.loewis.de>
	<94bdd2610912230250u2c0b7695n1be4ec4ae3c2c41b@mail.gmail.com>
	<4B3224B5.8000503@v.loewis.de>
	<94bdd2610912231045h5df841f5pe90cd46b387b0755@mail.gmail.com>
	<4B3266CF.7030705@v.loewis.de>
	<94bdd2610912231123o6d3236c7j289df78391083ac5@mail.gmail.com>
	<4B3279E9.4010507@v.loewis.de>
	<94bdd2610912231311h44e5563bn98fab09cab3c37f1@mail.gmail.com>
	<4B3324B2.3030708@v.loewis.de>
	<94bdd2610912240132t345b4d8bnc1bc81d5ae82b194@mail.gmail.com>
	<4B334626.6040505@v.loewis.de>
Message-ID: <3476.218.214.45.58.1263173741.squirrel@syd-srv02.ezyreg.com>


Hi Martin,

>From PEP-345,

> Requires-Dist: foo (1,!=1.3); platform.machine == 'i386'

I'd like to point to the following quote from http://www.apple.com/intel/

"Now every new Mac ships with an Intel processor. Experience delightful
responsiveness from the smallest Mac mini to the most beefed-up Mac Pro.
Use one of more than 7,000 universal applications that take full advantage
of the Intel chip. Run programs from your PowerPC-based Mac in
translation. Powered by Intel chips, your new Mac will do all those things
that only Macs can do ? and do so at an astonishing level of performance."

So the test would be true for some macs but not all, depending on how old
the mac is. Depending on whether the python implementation is properly
working or not.

I'll just make the point that it is going to be really difficult for
windows users to follow the hardware differences that exist in the mac
world.

Obviously, some macs have intel processors and some don't. How would a
developer reasonably be expected to know which are which? and what
difference does it make?

This information needs to be covered in the PEP for it to make it make
more sense to mr.average developer. At the moment it is somewhat
confusing.


David




From nad at acm.org  Mon Jan 11 04:11:49 2010
From: nad at acm.org (Ned Deily)
Date: Sun, 10 Jan 2010 19:11:49 -0800
Subject: [Distutils] Finishing PEP 345
References: <94bdd2610912180641i6df1a26co9c3ff34aba034982@mail.gmail.com>
	<4B301D54.6050109@v.loewis.de>
	<94bdd2610912230250u2c0b7695n1be4ec4ae3c2c41b@mail.gmail.com>
	<4B3224B5.8000503@v.loewis.de>
	<94bdd2610912231045h5df841f5pe90cd46b387b0755@mail.gmail.com>
	<4B3266CF.7030705@v.loewis.de>
	<94bdd2610912231123o6d3236c7j289df78391083ac5@mail.gmail.com>
	<4B3279E9.4010507@v.loewis.de>
	<94bdd2610912231311h44e5563bn98fab09cab3c37f1@mail.gmail.com>
	<4B3324B2.3030708@v.loewis.de>
	<94bdd2610912240132t345b4d8bnc1bc81d5ae82b194@mail.gmail.com>
	<4B334626.6040505@v.loewis.de>
	<3476.218.214.45.58.1263173741.squirrel@syd-srv02.ezyreg.com>
Message-ID: <nad-0C2679.19114810012010@news.gmane.org>

In article 
<3476.218.214.45.58.1263173741.squirrel at syd-srv02.ezyreg.com>,
 "David Lyon" <david.lyon at preisshare.net> wrote:
> >From PEP-345,
> 
> > Requires-Dist: foo (1,!=1.3); platform.machine == 'i386'
[...] 
> So the test would be true for some macs but not all, depending on how old
> the mac is. Depending on whether the python implementation is properly
> working or not.
> 
> I'll just make the point that it is going to be really difficult for
> windows users to follow the hardware differences that exist in the mac
> world.
> 
> Obviously, some macs have intel processors and some don't. How would a
> developer reasonably be expected to know which are which? and what
> difference does it make?
> 
> This information needs to be covered in the PEP for it to make it make
> more sense to mr.average developer. At the moment it is somewhat
> confusing.

In practice, this is seldom an issue on OS X as Pythons supplied by 
python.org and Apple are supplied as multi-architecture executables, 
i.e. the same file contains binaries for both 32-bit Intel and PPC CPUs 
and, in some cases, 64-bit Intel and 64-bit PPC as well.  The 
Apple-supplied build tool chain, and some code in the Python build 
scripts and Distutils, normally takes care of everything when building 
Python C extensions modules with no user intervention needed.  So there 
would almost never be a case where a platform.machine test would be 
needed for OS X.

-- 
 Ned Deily,
 nad at acm.org


From david.lyon at preisshare.net  Mon Jan 11 04:19:44 2010
From: david.lyon at preisshare.net (David Lyon)
Date: Mon, 11 Jan 2010 14:19:44 +1100 (EST)
Subject: [Distutils] Finishing PEP 345
In-Reply-To: <nad-0C2679.19114810012010@news.gmane.org>
References: <94bdd2610912180641i6df1a26co9c3ff34aba034982@mail.gmail.com>
	<4B301D54.6050109@v.loewis.de>
	<94bdd2610912230250u2c0b7695n1be4ec4ae3c2c41b@mail.gmail.com>
	<4B3224B5.8000503@v.loewis.de>
	<94bdd2610912231045h5df841f5pe90cd46b387b0755@mail.gmail.com>
	<4B3266CF.7030705@v.loewis.de>
	<94bdd2610912231123o6d3236c7j289df78391083ac5@mail.gmail.com>
	<4B3279E9.4010507@v.loewis.de>
	<94bdd2610912231311h44e5563bn98fab09cab3c37f1@mail.gmail.com>
	<4B3324B2.3030708@v.loewis.de>
	<94bdd2610912240132t345b4d8bnc1bc81d5ae82b194@mail.gmail.com>
	<4B334626.6040505@v.loewis.de>
	<3476.218.214.45.58.1263173741.squirrel@syd-srv02.ezyreg.com>
	<nad-0C2679.19114810012010@news.gmane.org>
Message-ID: <3734.218.214.45.58.1263179984.squirrel@syd-srv02.ezyreg.com>

> In article

>> ..
>> Obviously, some macs have intel processors and some don't. How would a
>> developer reasonably be expected to know which are which? and what
>> difference does it make?
>> ..
>
> In practice, this is seldom an issue on OS X as Pythons supplied by
> python.org and Apple are supplied as multi-architecture executables,
> i.e. the same file contains binaries for both 32-bit Intel and PPC CPUs
> and, in some cases, 64-bit Intel and 64-bit PPC as well.  The
> Apple-supplied build tool chain, and some code in the Python build
> scripts and Distutils, normally takes care of everything when building
> Python C extensions modules with no user intervention needed.  So there
> would almost never be a case where a platform.machine test would be
> needed for OS X.

I understand what you are saying and maybe you are 100% correct when you
are talking about the Apple platform.

PEP-345 doesn't mention platform.machine.

However, what you are now inferring is that there is no difference between
Apples and Windows based PCs. I'm not sure that this this is true or not.

My point, is how can a windows user be expected to know all that?

If 'i386' means all Apple and all Windows, then that needs to be clarified.

David





From nad at acm.org  Mon Jan 11 05:52:43 2010
From: nad at acm.org (Ned Deily)
Date: Sun, 10 Jan 2010 20:52:43 -0800
Subject: [Distutils] Finishing PEP 345
References: <94bdd2610912180641i6df1a26co9c3ff34aba034982@mail.gmail.com>
	<4B301D54.6050109@v.loewis.de>
	<94bdd2610912230250u2c0b7695n1be4ec4ae3c2c41b@mail.gmail.com>
	<4B3224B5.8000503@v.loewis.de>
	<94bdd2610912231045h5df841f5pe90cd46b387b0755@mail.gmail.com>
	<4B3266CF.7030705@v.loewis.de>
	<94bdd2610912231123o6d3236c7j289df78391083ac5@mail.gmail.com>
	<4B3279E9.4010507@v.loewis.de>
	<94bdd2610912231311h44e5563bn98fab09cab3c37f1@mail.gmail.com>
	<4B3324B2.3030708@v.loewis.de>
	<94bdd2610912240132t345b4d8bnc1bc81d5ae82b194@mail.gmail.com>
	<4B334626.6040505@v.loewis.de>
	<3476.218.214.45.58.1263173741.squirrel@syd-srv02.ezyreg.com>
	<nad-0C2679.19114810012010@news.gmane.org>
	<3734.218.214.45.58.1263179984.squirrel@syd-srv02.ezyreg.com>
Message-ID: <nad-EA9921.20524310012010@news.gmane.org>

In article 
<3734.218.214.45.58.1263179984.squirrel at syd-srv02.ezyreg.com>,
 "David Lyon" <david.lyon at preisshare.net> wrote:
>Ned Deily:
>>David Lyon:
>>>[...]
>>> Obviously, some macs have intel processors and some don't. How would 
a
>>> developer reasonably be expected to know which are which? and what
>>> difference does it make?
>>>[...]
>> In practice, this is seldom an issue on OS X as Pythons supplied by
>> python.org and Apple are supplied as multi-architecture executables,
>> i.e. the same file contains binaries for both 32-bit Intel and PPC 
CPUs
>> and, in some cases, 64-bit Intel and 64-bit PPC as well.  The
>> Apple-supplied build tool chain, and some code in the Python build
>> scripts and Distutils, normally takes care of everything when building
>> Python C extensions modules with no user intervention needed.  So 
there
>> would almost never be a case where a platform.machine test would be
>> needed for OS X. 
> I understand what you are saying and maybe you are 100% correct when you
> are talking about the Apple platform.
> 
> PEP-345 doesn't mention platform.machine.
> 
> However, what you are now inferring is that there is no difference between
> Apples and Windows based PCs. I'm not sure that this this is true or not.

I don't understand what you mean by that.  I neither inferred nor meant 
to imply anything about Windows-based PCs at all.
 
> My point, is how can a windows user be expected to know all that?
> 
> If 'i386' means all Apple and all Windows, then that needs to be clarified.

It states in PEP 345 that "the OS and CPU for which the binary 
distribution was compiled" is described in the Supported-Platform field.  
It also says that the semantic of that field are not specified by this 
PEP.  Presumably the value returned by distutils.get_platform() would be 
used for this field and would continue to be used as is current practice 
with setuptools/Distribute to qualify binary egg names, for instance.

BTW, I should have noted that Distutils has OS/CPU-specific rules for 
forming the platform name.  For OS X, it incorporates the minimum 
acceptable OS X level for the Python instance and extensions built with 
and for it (the "OS X deployment target", essentially an ABI level) and 
a meta machine type encoding the various architectures included in a 
multi-architecture executable.  A typical example:

>>> from distutils.util import get_platform
>>> get_platform()
'macosx-10.3-fat'

in this case, deployment target of OS X 10.3 or higher and "fat" is 
defined to mean 32-bit Intel and 32-bit PPC architectures are included.

It's also true, I think, that some, perhaps most, suppliers of 
distributions to PyPi no longer bother to supply binary distributions 
for OS X because there are so many variants and it is relatively 
painless to require their users to have installed the free but optional 
software development kit, Xcode, that Apple supplies with OS X releases.  
That lets Distutils take care of building C extensions with the proper 
gcc flags etc for the Python instance in use.

-- 
 Ned Deily,
 nad at acm.org


From david.lyon at preisshare.net  Mon Jan 11 06:13:46 2010
From: david.lyon at preisshare.net (David Lyon)
Date: Mon, 11 Jan 2010 16:13:46 +1100 (EST)
Subject: [Distutils] Finishing PEP 345
In-Reply-To: <nad-EA9921.20524310012010@news.gmane.org>
References: <94bdd2610912180641i6df1a26co9c3ff34aba034982@mail.gmail.com>
	<4B301D54.6050109@v.loewis.de>
	<94bdd2610912230250u2c0b7695n1be4ec4ae3c2c41b@mail.gmail.com>
	<4B3224B5.8000503@v.loewis.de>
	<94bdd2610912231045h5df841f5pe90cd46b387b0755@mail.gmail.com>
	<4B3266CF.7030705@v.loewis.de>
	<94bdd2610912231123o6d3236c7j289df78391083ac5@mail.gmail.com>
	<4B3279E9.4010507@v.loewis.de>
	<94bdd2610912231311h44e5563bn98fab09cab3c37f1@mail.gmail.com>
	<4B3324B2.3030708@v.loewis.de>
	<94bdd2610912240132t345b4d8bnc1bc81d5ae82b194@mail.gmail.com>
	<4B334626.6040505@v.loewis.de>
	<3476.218.214.45.58.1263173741.squirrel@syd-srv02.ezyreg.com>
	<nad-0C2679.19114810012010@news.gmane.org>
	<3734.218.214.45.58.1263179984.squirrel@syd-srv02.ezyreg.com>
	<nad-EA9921.20524310012010@news.gmane.org>
Message-ID: <4207.218.214.45.58.1263186826.squirrel@syd-srv02.ezyreg.com>



Ned Deily wrote:

> It states in PEP 345 that "the OS and CPU for which the binary
> distribution was compiled" is described in the Supported-Platform field.
> It also says that the semantic of that field are not specified by this
> PEP.

Well it should be made clear where those semantics are to be found.

> Presumably the value returned by distutils.get_platform() would be
> used for this field and would continue to be used as is current practice
> with setuptools/Distribute to qualify binary egg names, for instance.

If that is the case, the PEP should say so. Or, the list of presumptions
be made clear. I can't be expected to know all the presumptions.

My presumption as a long standing windows programmer is that somehow the
'i386' notation was somehow meant to be somehow related to windows. Since
in the past, windows users had intel processors and mac users had risc
(motorola) processors.

So.... 'i386' can mean Linux, Mac, or Windows.

That's fine. Whatever.

As long as we're clear on that.

David










From david.lyon at preisshare.net  Mon Jan 11 06:45:10 2010
From: david.lyon at preisshare.net (David Lyon)
Date: Mon, 11 Jan 2010 16:45:10 +1100 (EST)
Subject: [Distutils] Finishing PEP 345
In-Reply-To: <nad-EA9921.20524310012010@news.gmane.org>
References: <94bdd2610912180641i6df1a26co9c3ff34aba034982@mail.gmail.com>
	<4B301D54.6050109@v.loewis.de>
	<94bdd2610912230250u2c0b7695n1be4ec4ae3c2c41b@mail.gmail.com>
	<4B3224B5.8000503@v.loewis.de>
	<94bdd2610912231045h5df841f5pe90cd46b387b0755@mail.gmail.com>
	<4B3266CF.7030705@v.loewis.de>
	<94bdd2610912231123o6d3236c7j289df78391083ac5@mail.gmail.com>
	<4B3279E9.4010507@v.loewis.de>
	<94bdd2610912231311h44e5563bn98fab09cab3c37f1@mail.gmail.com>
	<4B3324B2.3030708@v.loewis.de>
	<94bdd2610912240132t345b4d8bnc1bc81d5ae82b194@mail.gmail.com>
	<4B334626.6040505@v.loewis.de>
	<3476.218.214.45.58.1263173741.squirrel@syd-srv02.ezyreg.com>
	<nad-0C2679.19114810012010@news.gmane.org>
	<3734.218.214.45.58.1263179984.squirrel@syd-srv02.ezyreg.com>
	<nad-EA9921.20524310012010@news.gmane.org>
Message-ID: <4247.218.214.45.58.1263188710.squirrel@syd-srv02.ezyreg.com>


Ned,

> It states in PEP 345 that "the OS and CPU for which the binary
> distribution was compiled" is described in the Supported-Platform field.

Yeah.. it does...

But the CPU in common use today is the 80586.

Renamed for marketing reasons to be the Pentium(tm)

So it is not technically correct to say compiled on a 'i386'
when it was actually compiled on a 80586.

Most Windows developers know they are using 80586 processors.

Most Windows users abandoned the 80386 processors a long time
ago.

The 80586 (pentium) gained a FPU, faster memory pipe-lining
and other blah-blah features.

I have an idea.. Why can't Windows users have the 'i586' notation
and Mac users have 'i386' if they are so happy with the i386 tag.

That should keep users happy here.

:-)

Please - let reality stay in this discussion. Reality is
not irrelevant.

David



From ben+python at benfinney.id.au  Mon Jan 11 09:09:36 2010
From: ben+python at benfinney.id.au (Ben Finney)
Date: Mon, 11 Jan 2010 19:09:36 +1100
Subject: [Distutils] [Catalog-sig] packaging terminology confusion
References: <4957f1ef1001070340y94da3cbgbc6dfe6c05028f3f@mail.gmail.com>
	<4957f1ef1001080900h52f271ccg45f71f376592db79@mail.gmail.com>
	<20100108174506.B2C473A4074@sparrow.telecommunity.com>
	<4957f1ef1001090713l1ca97cd0k8254e9ed3ae4e34e@mail.gmail.com>
	<20100109163905.4671C3A4074@sparrow.telecommunity.com>
	<49F3FD7D-00FF-48E0-88C8-7A753941BC15@twistedmatrix.com>
	<319e029f1001100254x74494ba5jef6093eb30b45c89@mail.gmail.com>
	<871vhyur0e.fsf@benfinney.id.au>
	<319e029f1001100352i70ef807dueaf99dcf0493273@mail.gmail.com>
	<87wrzpu113.fsf@benfinney.id.au>
	<319e029f1001101319h6ed7f2aayc8125aff500a45f8@mail.gmail.com>
Message-ID: <871vhxt64f.fsf@benfinney.id.au>

Lennart Regebro <regebro at gmail.com> writes:

> If you say "I need to install this package" it may technically be
> unclear if you mean the package "foo.bar" or the distribution
> "foo.bar-3.6.tgz", but that difference is not in that case
> significant. Installing the distribution and installing the package is
> in that case the same thing.

That case is far from the only one to consider, though. As already
pointed out, there are existing examples of ?foo-3.6.tar.gz? that
contain zero collection-of-module packages, and there are other such
examples that contain multiple collection-of-module packages.

So it's not the same thing (and I'm not saying you didn't know that).
It's needlessly confusing to expect people discussing these entities to
distinguish the name depending on how the modules are collected together
internally.

Such a thing will *still* be called ?a package? by programmers familiar
with the wider programming world, regardless what name Python has chosen
for them. I think it behooves us to choose terminology that acknowledges
that, even if it means asking the Python community to change its
terminology to be a little less parochial.

-- 
 \         ?Science is a way of trying not to fool yourself. The first |
  `\     principle is that you must not fool yourself, and you are the |
_o__)               easiest person to fool.? ?Richard P. Feynman, 1964 |
Ben Finney


From regebro at gmail.com  Mon Jan 11 09:35:50 2010
From: regebro at gmail.com (Lennart Regebro)
Date: Mon, 11 Jan 2010 09:35:50 +0100
Subject: [Distutils] [Catalog-sig] packaging terminology confusion
In-Reply-To: <871vhxt64f.fsf@benfinney.id.au>
References: <4957f1ef1001070340y94da3cbgbc6dfe6c05028f3f@mail.gmail.com>
	<4957f1ef1001090713l1ca97cd0k8254e9ed3ae4e34e@mail.gmail.com>
	<20100109163905.4671C3A4074@sparrow.telecommunity.com>
	<49F3FD7D-00FF-48E0-88C8-7A753941BC15@twistedmatrix.com>
	<319e029f1001100254x74494ba5jef6093eb30b45c89@mail.gmail.com>
	<871vhyur0e.fsf@benfinney.id.au>
	<319e029f1001100352i70ef807dueaf99dcf0493273@mail.gmail.com>
	<87wrzpu113.fsf@benfinney.id.au>
	<319e029f1001101319h6ed7f2aayc8125aff500a45f8@mail.gmail.com>
	<871vhxt64f.fsf@benfinney.id.au>
Message-ID: <319e029f1001110035v790017bbr8b517d1931b47e6e@mail.gmail.com>

On Mon, Jan 11, 2010 at 09:09, Ben Finney <ben+python at benfinney.id.au> wrote:
> Lennart Regebro <regebro at gmail.com> writes:
>
>> If you say "I need to install this package" it may technically be
>> unclear if you mean the package "foo.bar" or the distribution
>> "foo.bar-3.6.tgz", but that difference is not in that case
>> significant. Installing the distribution and installing the package is
>> in that case the same thing.
>
> That case is far from the only one to consider, though.

And I never said it was. I said that it's not a big problem because in
most cases the terminology mixup does not result in any practical
confusion. And I stand by that.

-- 
Lennart Regebro: Python, Zope, Plone, Grok
http://regebro.wordpress.com/
+33 661 58 14 64

From pachi at rvburke.com  Mon Jan 11 10:00:09 2010
From: pachi at rvburke.com (Rafael Villar Burke (Pachi))
Date: Mon, 11 Jan 2010 10:00:09 +0100
Subject: [Distutils] Finishing PEP 345
In-Reply-To: <4207.218.214.45.58.1263186826.squirrel@syd-srv02.ezyreg.com>
References: <94bdd2610912180641i6df1a26co9c3ff34aba034982@mail.gmail.com>	<4B301D54.6050109@v.loewis.de>	<94bdd2610912230250u2c0b7695n1be4ec4ae3c2c41b@mail.gmail.com>	<4B3224B5.8000503@v.loewis.de>	<94bdd2610912231045h5df841f5pe90cd46b387b0755@mail.gmail.com>	<4B3266CF.7030705@v.loewis.de>	<94bdd2610912231123o6d3236c7j289df78391083ac5@mail.gmail.com>	<4B3279E9.4010507@v.loewis.de>	<94bdd2610912231311h44e5563bn98fab09cab3c37f1@mail.gmail.com>	<4B3324B2.3030708@v.loewis.de>	<94bdd2610912240132t345b4d8bnc1bc81d5ae82b194@mail.gmail.com>	<4B334626.6040505@v.loewis.de>	<3476.218.214.45.58.1263173741.squirrel@syd-srv02.ezyreg.com>	<nad-0C2679.19114810012010@news.gmane.org>	<3734.218.214.45.58.1263179984.squirrel@syd-srv02.ezyreg.com>	<nad-EA9921.20524310012010@news.gmane.org>
	<4207.218.214.45.58.1263186826.squirrel@syd-srv02.ezyreg.com>
Message-ID: <4B4AE899.1070608@rvburke.com>

On 11/01/2010 6:13, David Lyon wrote:
> My presumption as a long standing windows programmer is that somehow the
> 'i386' notation was somehow meant to be somehow related to windows. Since
> in the past, windows users had intel processors and mac users had risc
> (motorola) processors.
>
> So.... 'i386' can mean Linux, Mac, or Windows.
>    
Windows (NT) used to run also on IA-32, MIPS and PowerPC processors too, 
and Windows (CE) also runs on other CPU FAMILIES other than i386 (ARM, 
MIPS, Hitachi SuperH).

So, no, i386 is just a widely used name to call the subset of the x86 
family that runs on 32bit (vs. the old 16bit members of the family, 
x86_64, etc). Significant compilers adopt this or a similar convention.

Regards,

Rafael Villar Burke

From ben+python at benfinney.id.au  Mon Jan 11 12:33:04 2010
From: ben+python at benfinney.id.au (Ben Finney)
Date: Mon, 11 Jan 2010 22:33:04 +1100
Subject: [Distutils] [Catalog-sig] packaging terminology confusion
References: <4957f1ef1001070340y94da3cbgbc6dfe6c05028f3f@mail.gmail.com>
	<4957f1ef1001090713l1ca97cd0k8254e9ed3ae4e34e@mail.gmail.com>
	<20100109163905.4671C3A4074@sparrow.telecommunity.com>
	<49F3FD7D-00FF-48E0-88C8-7A753941BC15@twistedmatrix.com>
	<319e029f1001100254x74494ba5jef6093eb30b45c89@mail.gmail.com>
	<871vhyur0e.fsf@benfinney.id.au>
	<319e029f1001100352i70ef807dueaf99dcf0493273@mail.gmail.com>
	<87wrzpu113.fsf@benfinney.id.au>
	<319e029f1001101319h6ed7f2aayc8125aff500a45f8@mail.gmail.com>
	<871vhxt64f.fsf@benfinney.id.au>
	<319e029f1001110035v790017bbr8b517d1931b47e6e@mail.gmail.com>
Message-ID: <87ocl0swpb.fsf@benfinney.id.au>

Lennart Regebro <regebro at gmail.com> writes:

> I said that it's not a big problem because in most cases the
> terminology mixup does not result in any practical confusion. And I
> stand by that.

So we're back to a tautology: where the terminology doesn't cause
confusion, it doesn't cause confusion. True, but not terribly useful.

-- 
 \          ?Rightful liberty is unobstructed action, according to our |
  `\        will, within limits drawn around us by the equal rights of |
_o__)                                       others.? ?Thomas Jefferson |
Ben Finney


From regebro at gmail.com  Mon Jan 11 12:53:41 2010
From: regebro at gmail.com (Lennart Regebro)
Date: Mon, 11 Jan 2010 12:53:41 +0100
Subject: [Distutils] [Catalog-sig] packaging terminology confusion
In-Reply-To: <87ocl0swpb.fsf@benfinney.id.au>
References: <4957f1ef1001070340y94da3cbgbc6dfe6c05028f3f@mail.gmail.com>
	<49F3FD7D-00FF-48E0-88C8-7A753941BC15@twistedmatrix.com>
	<319e029f1001100254x74494ba5jef6093eb30b45c89@mail.gmail.com>
	<871vhyur0e.fsf@benfinney.id.au>
	<319e029f1001100352i70ef807dueaf99dcf0493273@mail.gmail.com>
	<87wrzpu113.fsf@benfinney.id.au>
	<319e029f1001101319h6ed7f2aayc8125aff500a45f8@mail.gmail.com>
	<871vhxt64f.fsf@benfinney.id.au>
	<319e029f1001110035v790017bbr8b517d1931b47e6e@mail.gmail.com>
	<87ocl0swpb.fsf@benfinney.id.au>
Message-ID: <319e029f1001110353j395339d8n25e569340a325681@mail.gmail.com>

On Mon, Jan 11, 2010 at 12:33, Ben Finney <ben+python at benfinney.id.au> wrote:
> Lennart Regebro <regebro at gmail.com> writes:
>
>> I said that it's not a big problem because in most cases the
>> terminology mixup does not result in any practical confusion. And I
>> stand by that.
>
> So we're back to a tautology: where the terminology doesn't cause
> confusion, it doesn't cause confusion. True, but not terribly useful.

Except that this is not what I said. Please leave this kind of
responses to political discussion forums, they have no place here.

-- 
Lennart Regebro: Python, Zope, Plone, Grok
http://regebro.wordpress.com/
+33 661 58 14 64

From barry at python.org  Mon Jan 11 15:19:14 2010
From: barry at python.org (Barry Warsaw)
Date: Mon, 11 Jan 2010 09:19:14 -0500
Subject: [Distutils] [Catalog-sig]  packaging terminology confusion
In-Reply-To: <3282.218.214.45.58.1263171427.squirrel@syd-srv02.ezyreg.com>
References: <4957f1ef1001070340y94da3cbgbc6dfe6c05028f3f@mail.gmail.com>
	<20100107164433.662DE3A4074@sparrow.telecommunity.com>
	<4B464207.3030507@v.loewis.de>
	<20100107204102.D121C3A4074@sparrow.telecommunity.com>
	<4957f1ef1001071329m2de42256k31581cf2c6d0a1e0@mail.gmail.com>
	<94bdd2611001071339g15942eb3rcf00dcb8ddd4ee5e@mail.gmail.com>
	<4B46576F.7070309@egenix.com>
	<4957f1ef1001071357y382db993qffaee3b5ba2277e2@mail.gmail.com>
	<4B465C5F.7030609@egenix.com>
	<94bdd2611001071422p56182196mb974e747a0adecd2@mail.gmail.com>
	<65e0bb521001071943n7bbf739au3f9c7fc9175c6d01@mail.gmail.com>
	<723929E9-9814-4005-9025-4F38355DB5E7@twistedmatrix.com>
	<3282.218.214.45.58.1263171427.squirrel@syd-srv02.ezyreg.com>
Message-ID: <C0488BE7-A339-4D2B-B240-0BD1D71ECE79@python.org>

On Jan 10, 2010, at 7:57 PM, David Lyon wrote:

> As a regular developer, I'd call for a "L'Oeuf incredible". Excuse my bad
> french. A new egg to replace all the bad old eggs.
> 
> We need more simplicity in packaging in python..
> 
> "eggs" are cool. They're simple. They're what users want. They're what
> pypi needs.

+1

-Barry


From jmg3000 at gmail.com  Mon Jan 11 15:27:25 2010
From: jmg3000 at gmail.com (John Gabriele)
Date: Mon, 11 Jan 2010 09:27:25 -0500
Subject: [Distutils] [Catalog-sig] packaging terminology confusion
In-Reply-To: <319e029f1001110353j395339d8n25e569340a325681@mail.gmail.com>
References: <4957f1ef1001070340y94da3cbgbc6dfe6c05028f3f@mail.gmail.com>
	<319e029f1001100254x74494ba5jef6093eb30b45c89@mail.gmail.com>
	<871vhyur0e.fsf@benfinney.id.au>
	<319e029f1001100352i70ef807dueaf99dcf0493273@mail.gmail.com>
	<87wrzpu113.fsf@benfinney.id.au>
	<319e029f1001101319h6ed7f2aayc8125aff500a45f8@mail.gmail.com>
	<871vhxt64f.fsf@benfinney.id.au>
	<319e029f1001110035v790017bbr8b517d1931b47e6e@mail.gmail.com>
	<87ocl0swpb.fsf@benfinney.id.au>
	<319e029f1001110353j395339d8n25e569340a325681@mail.gmail.com>
Message-ID: <65e0bb521001110627i45f578c6s87f4f7e7a3c6b829@mail.gmail.com>

On Mon, Jan 11, 2010 at 6:53 AM, Lennart Regebro <regebro at gmail.com> wrote:
> On Mon, Jan 11, 2010 at 12:33, Ben Finney <ben+python at benfinney.id.au> wrote:
>> Lennart Regebro <regebro at gmail.com> writes:
>>
>>> I said that it's not a big problem because in most cases the
>>> terminology mixup does not result in any practical confusion. And I
>>> stand by that.
>>
>> So we're back to a tautology: where the terminology doesn't cause
>> confusion, it doesn't cause confusion. True, but not terribly useful.
>
> Except that this is not what I said.

Lennart, like you said, there's not much confusion for the majority of
cases where the distribution-package (distribution) contains only one
module-package. That is, if my CheeseWheel dist-package contains
exactly one module-package (named cheese_wheel), then there's pretty
much no confusion.

But, of course, there are cases when it's more complicated than that,
and (IMO) using one term for both will lead to confusion.

---John

From regebro at gmail.com  Mon Jan 11 16:15:19 2010
From: regebro at gmail.com (Lennart Regebro)
Date: Mon, 11 Jan 2010 16:15:19 +0100
Subject: [Distutils] [Catalog-sig] packaging terminology confusion
In-Reply-To: <65e0bb521001110627i45f578c6s87f4f7e7a3c6b829@mail.gmail.com>
References: <4957f1ef1001070340y94da3cbgbc6dfe6c05028f3f@mail.gmail.com>
	<871vhyur0e.fsf@benfinney.id.au>
	<319e029f1001100352i70ef807dueaf99dcf0493273@mail.gmail.com>
	<87wrzpu113.fsf@benfinney.id.au>
	<319e029f1001101319h6ed7f2aayc8125aff500a45f8@mail.gmail.com>
	<871vhxt64f.fsf@benfinney.id.au>
	<319e029f1001110035v790017bbr8b517d1931b47e6e@mail.gmail.com>
	<87ocl0swpb.fsf@benfinney.id.au>
	<319e029f1001110353j395339d8n25e569340a325681@mail.gmail.com>
	<65e0bb521001110627i45f578c6s87f4f7e7a3c6b829@mail.gmail.com>
Message-ID: <319e029f1001110715j3fae128rc1a7c0b57fe84087@mail.gmail.com>

On Mon, Jan 11, 2010 at 15:27, John Gabriele <jmg3000 at gmail.com> wrote:
> Lennart, like you said, there's not much confusion for the majority of
> cases where the distribution-package (distribution) contains only one
> module-package.

Correct, there is not a problem in the majority of the cases, and
hence, which I said, this is not a big problem. That's what I said,
and nothing else.

Glad we cleared that up. :)
-- 
Lennart Regebro: http://regebro.wordpress.com/
Python 3 Porting: http://python-incompatibility.googlecode.com/
+33 661 58 14 64

From jmg3000 at gmail.com  Mon Jan 11 16:17:13 2010
From: jmg3000 at gmail.com (John Gabriele)
Date: Mon, 11 Jan 2010 10:17:13 -0500
Subject: [Distutils] [Catalog-sig] packaging terminology confusion
In-Reply-To: <C0488BE7-A339-4D2B-B240-0BD1D71ECE79@python.org>
References: <4957f1ef1001070340y94da3cbgbc6dfe6c05028f3f@mail.gmail.com>
	<94bdd2611001071339g15942eb3rcf00dcb8ddd4ee5e@mail.gmail.com>
	<4B46576F.7070309@egenix.com>
	<4957f1ef1001071357y382db993qffaee3b5ba2277e2@mail.gmail.com>
	<4B465C5F.7030609@egenix.com>
	<94bdd2611001071422p56182196mb974e747a0adecd2@mail.gmail.com>
	<65e0bb521001071943n7bbf739au3f9c7fc9175c6d01@mail.gmail.com>
	<723929E9-9814-4005-9025-4F38355DB5E7@twistedmatrix.com>
	<3282.218.214.45.58.1263171427.squirrel@syd-srv02.ezyreg.com>
	<C0488BE7-A339-4D2B-B240-0BD1D71ECE79@python.org>
Message-ID: <65e0bb521001110717i3f3b8941t1048eb71b2789686@mail.gmail.com>

On Mon, Jan 11, 2010 at 9:19 AM, Barry Warsaw <barry at python.org> wrote:
> On Jan 10, 2010, at 7:57 PM, David Lyon wrote:
>
>> As a regular developer, I'd call for a "L'Oeuf incredible". Excuse my bad
>> french. A new egg to replace all the bad old eggs.
>>
>> We need more simplicity in packaging in python..
>>
>> "eggs" are cool. They're simple. They're what users want. They're what
>> pypi needs.
>
> +1
>

Do you mean, change the general name of these packaged up things from
"distributions" to "eggs"? So, we'd generically refer to, say,
"CheesyComestible-1.2.3.tgz" as an egg?

Interesting.

What term would you use to refer specifically to a ".egg" file?

---John

From sienkiew at stsci.edu  Mon Jan 11 16:19:11 2010
From: sienkiew at stsci.edu (Mark Sienkiewicz)
Date: Mon, 11 Jan 2010 10:19:11 -0500
Subject: [Distutils] Useless field (was Re:  Finishing PEP 345)
In-Reply-To: <nad-EA9921.20524310012010@news.gmane.org>
References: <94bdd2610912180641i6df1a26co9c3ff34aba034982@mail.gmail.com>	<4B301D54.6050109@v.loewis.de>	<94bdd2610912230250u2c0b7695n1be4ec4ae3c2c41b@mail.gmail.com>	<4B3224B5.8000503@v.loewis.de>	<94bdd2610912231045h5df841f5pe90cd46b387b0755@mail.gmail.com>	<4B3266CF.7030705@v.loewis.de>	<94bdd2610912231123o6d3236c7j289df78391083ac5@mail.gmail.com>	<4B3279E9.4010507@v.loewis.de>	<94bdd2610912231311h44e5563bn98fab09cab3c37f1@mail.gmail.com>	<4B3324B2.3030708@v.loewis.de>	<94bdd2610912240132t345b4d8bnc1bc81d5ae82b194@mail.gmail.com>	<4B334626.6040505@v.loewis.de>	<3476.218.214.45.58.1263173741.squirrel@syd-srv02.ezyreg.com>	<nad-0C2679.19114810012010@news.gmane.org>	<3734.218.214.45.58.1263179984.squirrel@syd-srv02.ezyreg.com>
	<nad-EA9921.20524310012010@news.gmane.org>
Message-ID: <4B4B416F.4000500@stsci.edu>

Ned Deily wrote:
> It states in PEP 345 that "the OS and CPU for which the binary 
> distribution was compiled" is described in the Supported-Platform field.  
> It also says that the semantic of that field are not specified by this 
> PEP.  Presumably the value returned by distutils.get_platform() would be 
> used for this field and would continue to be used as is current practice 
> with setuptools/Distribute to qualify binary egg names, for instance.
>   

Specifically, it says:

> Binary distributions containing a PKG-INFO file will use the 
> Supported-Platform field in their metadata to specify the OS and CPU 
> for which the binary distribution was compiled. The semantics of the 
> Supported-Platform field are not specified in this PEP.

Just to be clear, "semantics" refers to "what does this mean?"  If the 
semantics are not specified, then we don't know what it means, and the 
field does not contain any useful information.  Either the semantics 
should be defined, or the field should be removed.

So, what is this field for?  Can we give it a useful definition?

Mark S.


From bradallen137 at gmail.com  Mon Jan 11 16:46:08 2010
From: bradallen137 at gmail.com (Brad Allen)
Date: Mon, 11 Jan 2010 09:46:08 -0600
Subject: [Distutils] [Catalog-sig] packaging terminology confusion
In-Reply-To: <65e0bb521001110717i3f3b8941t1048eb71b2789686@mail.gmail.com>
References: <4957f1ef1001070340y94da3cbgbc6dfe6c05028f3f@mail.gmail.com>
	<4B46576F.7070309@egenix.com>
	<4957f1ef1001071357y382db993qffaee3b5ba2277e2@mail.gmail.com>
	<4B465C5F.7030609@egenix.com>
	<94bdd2611001071422p56182196mb974e747a0adecd2@mail.gmail.com>
	<65e0bb521001071943n7bbf739au3f9c7fc9175c6d01@mail.gmail.com>
	<723929E9-9814-4005-9025-4F38355DB5E7@twistedmatrix.com>
	<3282.218.214.45.58.1263171427.squirrel@syd-srv02.ezyreg.com>
	<C0488BE7-A339-4D2B-B240-0BD1D71ECE79@python.org>
	<65e0bb521001110717i3f3b8941t1048eb71b2789686@mail.gmail.com>
Message-ID: <4957f1ef1001110746u1a5017dq62b76690fbb7f4c4@mail.gmail.com>

On Mon, Jan 11, 2010 at 9:17 AM, John Gabriele <jmg3000 at gmail.com> wrote:

> Do you mean, change the general name of these packaged up things from
> "distributions" to "eggs"? So, we'd generically refer to, say,
> "CheesyComestible-1.2.3.tgz" as an egg?
>
> Interesting.
>
> What term would you use to refer specifically to a ".egg" file?

Boiled egg. :-)

From zooko at zooko.com  Mon Jan 11 18:08:43 2010
From: zooko at zooko.com (Zooko Wilcox-O'Hearn)
Date: Mon, 11 Jan 2010 10:08:43 -0700
Subject: [Distutils] [Catalog-sig]  packaging terminology confusion
In-Reply-To: <65e0bb521001071943n7bbf739au3f9c7fc9175c6d01@mail.gmail.com>
References: <4957f1ef1001070340y94da3cbgbc6dfe6c05028f3f@mail.gmail.com>
	<20100107164433.662DE3A4074@sparrow.telecommunity.com>
	<4B464207.3030507@v.loewis.de>
	<20100107204102.D121C3A4074@sparrow.telecommunity.com>
	<4957f1ef1001071329m2de42256k31581cf2c6d0a1e0@mail.gmail.com>
	<94bdd2611001071339g15942eb3rcf00dcb8ddd4ee5e@mail.gmail.com>
	<4B46576F.7070309@egenix.com>
	<4957f1ef1001071357y382db993qffaee3b5ba2277e2@mail.gmail.com>
	<4B465C5F.7030609@egenix.com>
	<94bdd2611001071422p56182196mb974e747a0adecd2@mail.gmail.com>
	<65e0bb521001071943n7bbf739au3f9c7fc9175c6d01@mail.gmail.com>
Message-ID: <06BFB135-97FE-4324-9899-6388C03CD303@zooko.com>

On Thursday, 2010-01-07, at 20:43 , John Gabriele wrote:

> So, here's a suggestion: just call both things (packages and  
> distributions) "packages", but then agree to fully qualify the  
> names when you need to avoid ambiguity, for example: "I just built  
> a distribution-package (or "dist-package" for short) and included  
> numerous module-packages in it."

+1

Thank you.

Your proposal has the advantage that it is what most users are  
already doing and will continue to do whether we like it or not.  :-)

> 3. People don't like calling those MyProject-1.0.2.tgz thingies  
> "distributions". They keep calling them packages, and when you  
> correct them, they say, "[sigh], fine. [eyes roll] 'distribution'."

Indeed, for most of the people I talk to (most of whom are not core  
committers to the Python project), I say "You want such-and-such a  
tool?  Please download the such-and-such package. See http:// 
pypi.python.org .", and they say "Ok".  If I say "Please download the  
such-and-such distribution." they say "Huh?".

This is a point that perhaps needs to be repeated.  We as distutils- 
sig don't have the option of educating all Python users about our  
peculiar terminology.  Maybe ten years ago, but today there are too  
many of them.  We have the option of either carrying on status quo  
with recurring confusion and clarification, or adopting the  
terminology that people already expect.

Regards,

Zooko

From martin at v.loewis.de  Mon Jan 11 18:49:36 2010
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Mon, 11 Jan 2010 18:49:36 +0100
Subject: [Distutils] Useless field (was Re:  Finishing PEP 345)
In-Reply-To: <4B4B416F.4000500@stsci.edu>
References: <94bdd2610912180641i6df1a26co9c3ff34aba034982@mail.gmail.com>	<4B301D54.6050109@v.loewis.de>	<94bdd2610912230250u2c0b7695n1be4ec4ae3c2c41b@mail.gmail.com>	<4B3224B5.8000503@v.loewis.de>	<94bdd2610912231045h5df841f5pe90cd46b387b0755@mail.gmail.com>	<4B3266CF.7030705@v.loewis.de>	<94bdd2610912231123o6d3236c7j289df78391083ac5@mail.gmail.com>	<4B3279E9.4010507@v.loewis.de>	<94bdd2610912231311h44e5563bn98fab09cab3c37f1@mail.gmail.com>	<4B3324B2.3030708@v.loewis.de>	<94bdd2610912240132t345b4d8bnc1bc81d5ae82b194@mail.gmail.com>	<4B334626.6040505@v.loewis.de>	<3476.218.214.45.58.1263173741.squirrel@syd-srv02.ezyreg.com>	<nad-0C2679.19114810012010@news.gmane.org>	<3734.218.214.45.58.1263179984.squirrel@syd-srv02.ezyreg.com>	<nad-EA9921.20524310012010@news.gmane.org>
	<4B4B416F.4000500@stsci.edu>
Message-ID: <4B4B64B0.3060206@v.loewis.de>

> So, what is this field for?

See the PEP:

"Binary distributions containing a PKG-INFO file will use the
Supported-Platform field in their metadata to specify the OS and CPU for
which the binary distribution was compiled."

Seems very clear to me.

>  Can we give it a useful definition?

Useful for what? To educate a human reader? I think it's useful as it
stands. To make it machine processable? That will be very difficult to
achieve.

Regards,
Martin

From sienkiew at stsci.edu  Mon Jan 11 21:44:15 2010
From: sienkiew at stsci.edu (Mark Sienkiewicz)
Date: Mon, 11 Jan 2010 15:44:15 -0500
Subject: [Distutils] Useless field (was Re:  Finishing PEP 345)
In-Reply-To: <4B4B64B0.3060206@v.loewis.de>
References: <94bdd2610912180641i6df1a26co9c3ff34aba034982@mail.gmail.com>	<4B301D54.6050109@v.loewis.de>	<94bdd2610912230250u2c0b7695n1be4ec4ae3c2c41b@mail.gmail.com>	<4B3224B5.8000503@v.loewis.de>	<94bdd2610912231045h5df841f5pe90cd46b387b0755@mail.gmail.com>	<4B3266CF.7030705@v.loewis.de>	<94bdd2610912231123o6d3236c7j289df78391083ac5@mail.gmail.com>	<4B3279E9.4010507@v.loewis.de>	<94bdd2610912231311h44e5563bn98fab09cab3c37f1@mail.gmail.com>	<4B3324B2.3030708@v.loewis.de>	<94bdd2610912240132t345b4d8bnc1bc81d5ae82b194@mail.gmail.com>	<4B334626.6040505@v.loewis.de>	<3476.218.214.45.58.1263173741.squirrel@syd-srv02.ezyreg.com>	<nad-0C2679.19114810012010@news.gmane.org>	<3734.218.214.45.58.1263179984.squirrel@syd-srv02.ezyreg.com>	<nad-EA9921.20524310012010@news.gmane.org>
	<4B4B416F.4000500@stsci.edu> <4B4B64B0.3060206@v.loewis.de>
Message-ID: <4B4B8D9F.4020203@stsci.edu>

Martin v. L?wis wrote:
>> So, what is this field for?
>>     
>
> See the PEP:
>
> "Binary distributions containing a PKG-INFO file will use the
> Supported-Platform field in their metadata to specify the OS and CPU for
> which the binary distribution was compiled."
>
> Seems very clear to me.
>   


The question "what it it for?" needs a better answer than that.  Who 
looks at this field?  What do they do with the data that it contains?  
When creating a record, how do I know the correct value to put in this 
field?  Can I just make up anything, like "Supported-Platform: my new 
laptop"?


>>  Can we give it a useful definition?
>>     
>
> Useful for what? To educate a human reader? I think it's useful as it
> stands. To make it machine processable? That will be very difficult to
> achieve.
>   

Useful for me to understand why I should bother the fill in this field.  
Useful for me to understand why it is in the specification in the first 
place.

You imply that this field is not intended to be machine processable.  
That means that:

- packaging tools will not look at it, because the tools don't know what 
it means

- database searches of available packages will not look at it, because 
the databases don't know what it means

In that case, it is as simple as adding "This field is intended only as 
a hint to a human reader about the build environment.  Because there is 
no specification for the content of this field, it does not make sense 
to do searches or comparisons on this field.  When writing a new record, 
put whatever descriptive text about the platform that you think might be 
useful."

If that is a correct description, then that description should go in the 
PEP.

Mark S.


From martin at v.loewis.de  Mon Jan 11 22:18:12 2010
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Mon, 11 Jan 2010 22:18:12 +0100
Subject: [Distutils] Useless field (was Re:  Finishing PEP 345)
In-Reply-To: <4B4B8D9F.4020203@stsci.edu>
References: <94bdd2610912180641i6df1a26co9c3ff34aba034982@mail.gmail.com>	<4B301D54.6050109@v.loewis.de>	<94bdd2610912230250u2c0b7695n1be4ec4ae3c2c41b@mail.gmail.com>	<4B3224B5.8000503@v.loewis.de>	<94bdd2610912231045h5df841f5pe90cd46b387b0755@mail.gmail.com>	<4B3266CF.7030705@v.loewis.de>	<94bdd2610912231123o6d3236c7j289df78391083ac5@mail.gmail.com>	<4B3279E9.4010507@v.loewis.de>	<94bdd2610912231311h44e5563bn98fab09cab3c37f1@mail.gmail.com>	<4B3324B2.3030708@v.loewis.de>	<94bdd2610912240132t345b4d8bnc1bc81d5ae82b194@mail.gmail.com>	<4B334626.6040505@v.loewis.de>	<3476.218.214.45.58.1263173741.squirrel@syd-srv02.ezyreg.com>	<nad-0C2679.19114810012010@news.gmane.org>	<3734.218.214.45.58.1263179984.squirrel@syd-srv02.ezyreg.com>	<nad-EA9921.20524310012010@news.gmane.org>
	<4B4B416F.4000500@stsci.edu> <4B4B64B0.3060206@v.loewis.de>
	<4B4B8D9F.4020203@stsci.edu>
Message-ID: <4B4B9594.4050603@v.loewis.de>

> The question "what it it for?" needs a better answer than that.  Who
> looks at this field?  What do they do with the data that it contains? 
> When creating a record, how do I know the correct value to put in this
> field?  Can I just make up anything, like "Supported-Platform: my new
> laptop"?

The spec says

"The semantics of the Supported-Platform field are not specified in this
PEP."

which answers all these questions: people will look at the field, and
proprietary software may do so as well. What they do with the data is
out of scope of the PEP. Any value is correct. You can certainly put
"my new laptop" into the field.

Now, you may not *like* that specification. However, it is fairly clear.

> Useful for me to understand why I should bother the fill in this field. 

If you know it's primarily for a human reader (as the text says), you
should also know whether you can bother to fill in the field.

It depends on your package, of course: for some package,
supported-platform may be useful, for others, it may not.

> Useful for me to understand why it is in the specification in the first
> place.

This is also (implicit) in the specification: it's a compromise. Without
knowing the history, it seems that some party wanted such a field, and
another party didn't think it was feasible or reasonable to provide.
Hence the compromise.

Notice that "uninterpreted data" is not unheard of as a concept:
Summary, Description, Keywords, Author, Maintainer are all of the
same kind.
> 
> You imply that this field is not intended to be machine processable. 
> That means that:
> 
> - packaging tools will not look at it, because the tools don't know what
> it means

Correct.

> - database searches of available packages will not look at it, because
> the databases don't know what it means

I don't know where you get that implication from. By the same reasoning,
the database search wouldn't look at Summary or Description. I can
assure you that they do.

> In that case, it is as simple as adding "This field is intended only as
> a hint to a human reader about the build environment.  Because there is
> no specification for the content of this field, it does not make sense
> to do searches or comparisons on this field.  When writing a new record,
> put whatever descriptive text about the platform that you think might be
> useful."
> 
> If that is a correct description, then that description should go in the
> PEP.

I wouldn't mind it being added. However, the wording that is currently
there already says exactly that (and more).

Regards,
Martin

From Ronny.Pfannschmidt at gmx.de  Mon Jan 11 23:24:06 2010
From: Ronny.Pfannschmidt at gmx.de (Ronny Pfannschmidt)
Date: Mon, 11 Jan 2010 23:24:06 +0100
Subject: [Distutils] refining the idea of entrypoints and their metadata
Message-ID: <1263248646.30123.113.camel@localhost>

Hi,

while toying with the entrypoint system, i repeatedly ran into the need
of having additional metadata prior to importing

In Plugins that only handle certain filetypes/extensions/mimetypes might
profit from the additional metadata (while also defering imports)

The same goes for my library anyvc that needs to know what directories
to check for, however usually the directory checking is a lot faster
than doing the imports (and implementing custom lazy importing is pain).

So i propose supporting to store additional metadata along with the
entrypoints.

the current data is stored in the form of a ini file a la:
        [group]
        namea = import [extras]
        nameb = import
        [another group]
        ...

Which basically translates to the following data entries per entrypoint:

:group: the group of that entrypoint
:name: the name
:import: the default import
:extras: the setuptools extra dependencies

Now i'd like to add custom entries to that,
and i see various ways to store those

* list of json objects includ (strongly prefered by me)
* adding [group:name] sections right after each group section
  that encode the additional metadata (see examples)


This would allow basic uses like::

        [wiki.renderer]
        creole = foo.bar:CreoleRenderer [creole]
        [wiki.renderer:creole]
        mimetypes: wiki/creole
        fnmaps: *.creole *.wiki
        
or::
        [pygments.lexer]
        Brainfuck = bf:BfLexer
        [pygments.lexer:brainfuck]
        mimetypes: brainfuck?!
        filenames: *.bf *.brainfuck
        aliases: bf

Additionaly the load method of the Entrypoint class could grow a
optional parameter for alternative imports

That would allow listings like::

     [anyvc.backend]
     subversion = anyvc.subversion [subversion]
     mercurial = anyvc.mercurial [mercurial]

        [anyvc.backend:subversion]
        aliases: svn 
        workdir_adm_dir: .svn/
        workdir_has_paths: .svn/entries .svn/props/
        repo_has_paths: format hooks/ db/ conf/ locks/
        workdir: anyvc.subversion.workdir:SubversionWorkdir
        repo: anyvc.subversion.repo:SubversionRepository
        
        [anyvc.backend:mercurial]
        aliases: hg
        workdir_adm_dir: .hg
        workdir_has_paths: .hg/requires .hg/store/
        repo_has_paths: .hg/requires .hg/store/
        workdir: anyvc.mercurial.workdir:HgWorkdir
        repo: anyvc.mercurial.repo:HgRepository

Then one could just choose specific imports by passing the new name of
the import to the load function like::

        workdir_type = ep.load('workdir')
        repo_type = ep.load('repo')
        
As you can see the above is a pretty rough idea and in need of
refinements.

The advantage over just having sets of Entrypoints with group, name,
import is that this metadata extension provides a much more pleasant
entry to medium sized feature and removes the need to import for various
metadata checks (in some of my cases, importing entrypoints completely
dominated the execution times) 

I also played with the idea of having separate entrypoints for metadata
and modules, but there are many cases where that kind of use seems
unpractical or really just unpleasant to me.

An additional item of interest is having multiple Entrypoints which do
the same thing but, are implemented using different dependencies (and i
want them ordered by some kind of preference/priority).
(but i suppose in case of doubt i could implement those as sort by a
metadata key)


Please Discuss!

Regards Ronny




From david.lyon at preisshare.net  Tue Jan 12 01:09:53 2010
From: david.lyon at preisshare.net (David Lyon)
Date: Tue, 12 Jan 2010 11:09:53 +1100 (EST)
Subject: [Distutils] [Catalog-sig] packaging terminology confusion
In-Reply-To: <65e0bb521001110717i3f3b8941t1048eb71b2789686@mail.gmail.com>
References: <4957f1ef1001070340y94da3cbgbc6dfe6c05028f3f@mail.gmail.com>
	<94bdd2611001071339g15942eb3rcf00dcb8ddd4ee5e@mail.gmail.com>
	<4B46576F.7070309@egenix.com>
	<4957f1ef1001071357y382db993qffaee3b5ba2277e2@mail.gmail.com>
	<4B465C5F.7030609@egenix.com>
	<94bdd2611001071422p56182196mb974e747a0adecd2@mail.gmail.com>
	<65e0bb521001071943n7bbf739au3f9c7fc9175c6d01@mail.gmail.com>
	<723929E9-9814-4005-9025-4F38355DB5E7@twistedmatrix.com>
	<3282.218.214.45.58.1263171427.squirrel@syd-srv02.ezyreg.com>
	<C0488BE7-A339-4D2B-B240-0BD1D71ECE79@python.org>
	<65e0bb521001110717i3f3b8941t1048eb71b2789686@mail.gmail.com>
Message-ID: <1289.218.214.45.58.1263254993.squirrel@syd-srv02.ezyreg.com>

> On Mon, Jan 11, 2010 at 9:19 AM, Barry Warsaw <barry at python.org> wrote:

> Do you mean, change the general name of these packaged up things from
> "distributions" to "eggs"?

What I mean is that the egg concept abstracts all the packaging
details from the user extremely well.

If a user gets told that all python packages come as python
eggs, they just accept that and move on.

If we could move to a position (slowly) whereby we had all
packages as .egg files, that would make life simpler for
users. It is less choices.

> So, we'd generically refer to, say,
> "CheesyComestible-1.2.3.tgz" as an egg?

No.

Just "CheesyComestible-1.2.3.egg"

Eliminate : CheesyComestible-1.2.3.zip CheesyComestible-1.2.3.exe
CheesyComestible-1.2.3.tar.gz CheesyComestible-1.2.3.bz2

Unneccessary and confusing.

> What term would you use to refer specifically to a ".egg" file?

Just "Python Egg".

David





From david.lyon at preisshare.net  Tue Jan 12 02:01:07 2010
From: david.lyon at preisshare.net (David Lyon)
Date: Tue, 12 Jan 2010 12:01:07 +1100 (EST)
Subject: [Distutils] current preferred way to specify dependencies?
 future?
In-Reply-To: <4B463BB7.2050501@v.loewis.de>
References: <65e0bb521001051929m7674b0co25b707120764a440@mail.gmail.com>
	<1716.218.214.45.58.1262749446.squirrel@syd-srv02.ezyreg.com>
	<4B44254F.4000501@v.loewis.de>
	<3473.165.228.171.167.1262853597.squirrel@syd-srv02.ezyreg.com>
	<4B463BB7.2050501@v.loewis.de>
Message-ID: <1530.218.214.45.58.1263258067.squirrel@syd-srv02.ezyreg.com>


Martin,

> py> import platform
> py> platform.machine()
> 'i686'
>
> 'i686' maps very well to a real machine on the market, namely to the
> machine on which I'm typing this right now.

Ok.

When I run the same thing:

  >import platform
  >platform.machine()
  >'x86'

So what is being proposed isn't very repeatable.

>>> Whereas using the built-in platform identification mechanism
>>> would be extremely difficult?

Difficult for developers to predict other environments.

One reason is the lack of clear documentation.

I'm only asking for clearer documentation.

> If you don't like the values that Python reports, get Python
> fixed. The PEP will then fix itself automatically, the way
> it is specified.

Ok. That will work for future versions.

But it generates a nightmare scenario for application developers
installing on existing python installations. Their knowledge
must increase to be the same as your knowledge.

That is unfair.

> I disagree that the values Python reports are erroneous. They
> indicate fairly reliably the relevant characteristics of the
> system Python runs on.

But what is happening is that we are bypassing metadata by
including system calls.

That *ain't* metadata.

That is an error.

David





From david.lyon at preisshare.net  Tue Jan 12 02:06:17 2010
From: david.lyon at preisshare.net (David Lyon)
Date: Tue, 12 Jan 2010 12:06:17 +1100 (EST)
Subject: [Distutils] Finishing PEP 345
In-Reply-To: <4B4AE899.1070608@rvburke.com>
References: <94bdd2610912180641i6df1a26co9c3ff34aba034982@mail.gmail.com>
	<4B301D54.6050109@v.loewis.de>
	<94bdd2610912230250u2c0b7695n1be4ec4ae3c2c41b@mail.gmail.com>
	<4B3224B5.8000503@v.loewis.de>
	<94bdd2610912231045h5df841f5pe90cd46b387b0755@mail.gmail.com>
	<4B3266CF.7030705@v.loewis.de>
	<94bdd2610912231123o6d3236c7j289df78391083ac5@mail.gmail.com>
	<4B3279E9.4010507@v.loewis.de>
	<94bdd2610912231311h44e5563bn98fab09cab3c37f1@mail.gmail.com>
	<4B3324B2.3030708@v.loewis.de>
	<94bdd2610912240132t345b4d8bnc1bc81d5ae82b194@mail.gmail.com>
	<4B334626.6040505@v.loewis.de>
	<3476.218.214.45.58.1263173741.squirrel@syd-srv02.ezyreg.com>
	<nad-0C2679.19114810012010@news.gmane.org>
	<3734.218.214.45.58.1263179984.squirrel@syd-srv02.ezyreg.com>
	<nad-EA9921.20524310012010@news.gmane.org>
	<4207.218.214.45.58.1263186826.squirrel@syd-srv02.ezyreg.com>
	<4B4AE899.1070608@rvburke.com>
Message-ID: <1542.218.214.45.58.1263258377.squirrel@syd-srv02.ezyreg.com>


Rafeal wrote:

> Windows (NT) used to run also on IA-32, MIPS and PowerPC processors too,
> and Windows (CE) also runs on other CPU FAMILIES other than i386 (ARM,
> MIPS, Hitachi SuperH).
>
> So, no, i386 is just a widely used name to call the subset of the x86
> family that runs on 32bit (vs. the old 16bit members of the family,
> x86_64, etc). Significant compilers adopt this or a similar convention.

Exactly.

So we really get no clear and simple guidence from the
PEP on how to specify dependencies for different platforms.

The fact that this is as clear as mud for an end-developer
is my issue.

David



From ssteinerx at gmail.com  Tue Jan 12 02:22:41 2010
From: ssteinerx at gmail.com (ssteinerX@gmail.com)
Date: Mon, 11 Jan 2010 20:22:41 -0500
Subject: [Distutils] current preferred way to specify dependencies?
	future?
In-Reply-To: <1530.218.214.45.58.1263258067.squirrel@syd-srv02.ezyreg.com>
References: <65e0bb521001051929m7674b0co25b707120764a440@mail.gmail.com>
	<1716.218.214.45.58.1262749446.squirrel@syd-srv02.ezyreg.com>
	<4B44254F.4000501@v.loewis.de>
	<3473.165.228.171.167.1262853597.squirrel@syd-srv02.ezyreg.com>
	<4B463BB7.2050501@v.loewis.de>
	<1530.218.214.45.58.1263258067.squirrel@syd-srv02.ezyreg.com>
Message-ID: <8BBC9FFF-774E-4E11-9D75-A86870BFFFBE@gmail.com>

On Jan 11, 2010, at 8:01 PM, David Lyon wrote:
> When I run the same thing:
> 
>> import platform
>> platform.machine()
>> 'x86'

Just as a data point, I get:

import platform
platform.machine()
'i386'

on a dual processor quad core Mac Pro.

S


From ben+python at benfinney.id.au  Tue Jan 12 02:38:23 2010
From: ben+python at benfinney.id.au (Ben Finney)
Date: Tue, 12 Jan 2010 12:38:23 +1100
Subject: [Distutils] packaging terminology confusion
References: <4957f1ef1001070340y94da3cbgbc6dfe6c05028f3f@mail.gmail.com>
	<94bdd2611001071339g15942eb3rcf00dcb8ddd4ee5e@mail.gmail.com>
	<4B46576F.7070309@egenix.com>
	<4957f1ef1001071357y382db993qffaee3b5ba2277e2@mail.gmail.com>
	<4B465C5F.7030609@egenix.com>
	<94bdd2611001071422p56182196mb974e747a0adecd2@mail.gmail.com>
	<65e0bb521001071943n7bbf739au3f9c7fc9175c6d01@mail.gmail.com>
	<723929E9-9814-4005-9025-4F38355DB5E7@twistedmatrix.com>
	<3282.218.214.45.58.1263171427.squirrel@syd-srv02.ezyreg.com>
	<C0488BE7-A339-4D2B-B240-0BD1D71ECE79@python.org>
	<65e0bb521001110717i3f3b8941t1048eb71b2789686@mail.gmail.com>
	<1289.218.214.45.58.1263254993.squirrel@syd-srv02.ezyreg.com>
Message-ID: <87k4voqf00.fsf@benfinney.id.au>

"David Lyon" <david.lyon at preisshare.net> writes:

> Just "CheesyComestible-1.2.3.egg"
>
> Eliminate : CheesyComestible-1.2.3.zip CheesyComestible-1.2.3.exe
> CheesyComestible-1.2.3.tar.gz CheesyComestible-1.2.3.bz2
>
> Unneccessary and confusing.

How are they unnecessary? There needs to be, at least, a difference
between the source package and the binary package. Further, you (IIRC)
have been arguing for Windows executable installers, which are
necessarily going to be different from either the source package or the
binary package for non-Windows systems.

All of them *are* ?the package?, at a particular version, in different
and necessary forms.

-- 
 \      ?It is the integrity of each individual human that is in final |
  `\        examination. On personal integrity hangs humanity's fate.? |
_o__)               ?Richard Buckminster Fuller, _Critical Path_, 1981 |
Ben Finney


From david.lyon at preisshare.net  Tue Jan 12 02:44:49 2010
From: david.lyon at preisshare.net (David Lyon)
Date: Tue, 12 Jan 2010 12:44:49 +1100 (EST)
Subject: [Distutils] [Catalog-sig]   packaging terminology confusion
In-Reply-To: <87k4voqf00.fsf@benfinney.id.au>
References: <4957f1ef1001070340y94da3cbgbc6dfe6c05028f3f@mail.gmail.com>
	<94bdd2611001071339g15942eb3rcf00dcb8ddd4ee5e@mail.gmail.com>
	<4B46576F.7070309@egenix.com>
	<4957f1ef1001071357y382db993qffaee3b5ba2277e2@mail.gmail.com>
	<4B465C5F.7030609@egenix.com>
	<94bdd2611001071422p56182196mb974e747a0adecd2@mail.gmail.com>
	<65e0bb521001071943n7bbf739au3f9c7fc9175c6d01@mail.gmail.com>
	<723929E9-9814-4005-9025-4F38355DB5E7@twistedmatrix.com>
	<3282.218.214.45.58.1263171427.squirrel@syd-srv02.ezyreg.com>
	<C0488BE7-A339-4D2B-B240-0BD1D71ECE79@python.org>
	<65e0bb521001110717i3f3b8941t1048eb71b2789686@mail.gmail.com>
	<1289.218.214.45.58.1263254993.squirrel@syd-srv02.ezyreg.com>
	<87k4voqf00.fsf@benfinney.id.au>
Message-ID: <1640.218.214.45.58.1263260689.squirrel@syd-srv02.ezyreg.com>

Ben Finney writes:
>> Eliminate : CheesyComestible-1.2.3.zip CheesyComestible-1.2.3.exe
>> CheesyComestible-1.2.3.tar.gz CheesyComestible-1.2.3.bz2
>>
>> Unneccessary and confusing.
>
> How are they unnecessary? There needs to be, at least, a difference
> between the source package and the binary package.

Why?

If you have a zip/archive file, you can put anything in it. No reason why
'everything' can't go in it.

A "L'Oeuf incredible" might include a Python 2.x and Python 3.x code set,
make code for linux, .pyd for windows.

It would be so un-confusing to have an egg like that.

> Further, you (IIRC)
> have been arguing for Windows executable installers, which are
> necessarily going to be different from either the source package or the
> binary package for non-Windows systems.

I don't like those. I'd prefer as a security issue thing to have a .egg
package, associated with python, that I can click on with my browser, and
download and install into python automatically.

> All of them *are* the package, at a particular version, in different
> and necessary forms.

It's just confusing that way. But I understand all the history.

We had divergence of all these package forms..

Now we need convergence to a new singular package form.

David





From pje at telecommunity.com  Tue Jan 12 07:28:57 2010
From: pje at telecommunity.com (P.J. Eby)
Date: Tue, 12 Jan 2010 01:28:57 -0500
Subject: [Distutils] refining the idea of entrypoints and their metadata
In-Reply-To: <1263248646.30123.113.camel@localhost>
References: <1263248646.30123.113.camel@localhost>
Message-ID: <20100112062900.28DC63A4065@sparrow.telecommunity.com>

At 11:24 PM 1/11/2010 +0100, Ronny Pfannschmidt wrote:
>Hi,
>
>while toying with the entrypoint system, i repeatedly ran into the need
>of having additional metadata prior to importing
>
>In Plugins that only handle certain filetypes/extensions/mimetypes might
>profit from the additional metadata (while also defering imports)
>
>The same goes for my library anyvc that needs to know what directories
>to check for, however usually the directory checking is a lot faster
>than doing the imports (and implementing custom lazy importing is pain).
>
>So i propose supporting to store additional metadata along with the
>entrypoints.

Just FYI, there is nothing stopping you from implementing something 
like this with an egg_info writer plugin and a custom setup argument:

   http://peak.telecommunity.com/DevCenter/setuptools#adding-setup-arguments
   http://peak.telecommunity.com/DevCenter/setuptools#adding-new-egg-info-files

You could then use the pkg_resources discovery APIs to find distributions:

    http://peak.telecommunity.com/DevCenter/PkgResources#getting-or-creating-distributions

And then pull out the metadata via the API:

    http://peak.telecommunity.com/DevCenter/PkgResources#imetadataprovider-methods

This is exactly how standard entry points are implemented now, so you 
can use this as a guide.

The i18n support for Chandler uses a similar approach, bundling a 
resources.ini in the egg_info metadata, that lists message catalogs 
and other localization resources included in the relevant 
plugin.  (Chandler plugins can provide translations for strings in 
other Chandler plugins, so that e.g. you can distribute a 
multi-plugin localization plugin.)

(Btw, these comments should not be construed as saying a more 
sophisticated system is a bad idea or anything like that, I'm just 
pointing out that you need not wait for someone else to implement 
this for you, as the hooks to do it on your own are documented and 
ready to use.  And perhaps you can then promote your implementation 
as a defacto or dejure standard.  ;-) )


From Ronny.Pfannschmidt at gmx.de  Tue Jan 12 09:10:45 2010
From: Ronny.Pfannschmidt at gmx.de (Ronny Pfannschmidt)
Date: Tue, 12 Jan 2010 09:10:45 +0100
Subject: [Distutils] refining the idea of entrypoints and their metadata
In-Reply-To: <20100112062900.28DC63A4065@sparrow.telecommunity.com>
References: <1263248646.30123.113.camel@localhost>
	<20100112062900.28DC63A4065@sparrow.telecommunity.com>
Message-ID: <1263283845.8004.36.camel@localhost>

On Tue, 2010-01-12 at 01:28 -0500, P.J. Eby wrote:
> At 11:24 PM 1/11/2010 +0100, Ronny Pfannschmidt wrote:
> >Hi,
> >
> >while toying with the entrypoint system, i repeatedly ran into the need
> >of having additional metadata prior to importing
> >
> >In Plugins that only handle certain filetypes/extensions/mimetypes might
> >profit from the additional metadata (while also defering imports)
> >
> >The same goes for my library anyvc that needs to know what directories
> >to check for, however usually the directory checking is a lot faster
> >than doing the imports (and implementing custom lazy importing is pain).
> >
> >So i propose supporting to store additional metadata along with the
> >entrypoints.
> 
> Just FYI, there is nothing stopping you from implementing something 
> like this with an egg_info writer plugin and a custom setup argument:
> 
>    http://peak.telecommunity.com/DevCenter/setuptools#adding-setup-arguments
>    http://peak.telecommunity.com/DevCenter/setuptools#adding-new-egg-info-files
> 
> You could then use the pkg_resources discovery APIs to find distributions:
> 
>     http://peak.telecommunity.com/DevCenter/PkgResources#getting-or-creating-distributions
> 
> And then pull out the metadata via the API:
> 
>     http://peak.telecommunity.com/DevCenter/PkgResources#imetadataprovider-methods
> 
> This is exactly how standard entry points are implemented now, so you 
> can use this as a guide.

This is a good inspiration on getting started.

> The i18n support for Chandler uses a similar approach, bundling a 
> resources.ini in the egg_info metadata, that lists message catalogs 
> and other localization resources included in the relevant 
> plugin.  (Chandler plugins can provide translations for strings in 
> other Chandler plugins, so that e.g. you can distribute a 
> multi-plugin localization plugin.)
> 
> (Btw, these comments should not be construed as saying a more 
> sophisticated system is a bad idea or anything like that, I'm just 
> pointing out that you need not wait for someone else to implement 
> this for you, as the hooks to do it on your own are documented and 
> ready to use.  And perhaps you can then promote your implementation 
> as a defacto or dejure standard.  ;-) )

I just wanted discussion first in order to get rid of initial stupid
ideas - and your hint to the extension system was pretty helpfull in
destroying the stupid idea of needing to hack into entrypoint parsing
directly.

I'll start to implement my current needs for setuptools/distribute 0.6
and distribute 0.7 and post for peer-review once i get to a acceptable
point.

Regards Ronny


From nate at psu.edu  Tue Jan 12 19:08:09 2010
From: nate at psu.edu (Nate Coraor)
Date: Tue, 12 Jan 2010 13:08:09 -0500
Subject: [Distutils] Platform naming standardization
Message-ID: <4B4CBA89.9020000@psu.edu>

Hi,

I'm involved with a software project that makes extensive use of third 
party modules with C extensions.  To ease installation, we pre-build 
them for some popular platforms and provide a distribution system for 
the app to fetch them.

setuptools uses distutils.util.get_platform() to decide whether an egg 
found on the path is compatible, with some special extra magic added in 
for Mac OS X.  Unfortunately, get_platform() as implemented does not 
provide enough information to ensure binary compatibility.

Among the platforms we use, these are the issues:

1) On all platforms, interpreters compiled with UCS2 and UCS4 are binary 
incompatible, so modules compiled on one will fail to import on the 
other.  We work around this by appending -ucsX to the platform string, 
based on the value of sys.maxunicode.

2) On OS X, the modification to the value returned by 
pkg_resources.get_platform() isn't correct for fat version of Python 
2.5, as detailed in setuptools issue 19.  To solve that, we're using the 
patch I submitted to the issue (with a couple recent changes).

3) On Solaris (and likely other UNIXes where 32 and 64 bit user spaces 
coexist), no distinction is made between a 32 bit and 64 bit 
interpreter, and they are not binary compatible.  We work around this by 
checking sys.maxint, and right now in testing I'm appending -32 or -64 
to the platform string (but before -ucsX).  I haven't settled on this, 
though, since I have a feeling maybe it should be part of the arch 
(sun4u_32, i86pc_64, etc.) or something like 'solaris32' and 'solaris64' 
instead of 'solaris'.

4) Also on Solaris, the OS is binary compatible with older releases, so 
Solaris binary distributors will often build on the oldest reasonable 
release.  This is not possible with setuptools now, although extending 
pkg_resources.compatible_platforms() in pretty much the same manner as 
is done for OS X solves this (and I can provide a patch).

It's not even crucial to me that these be fixed, but before I continue 
to hack up the platform string, I wanted to ask the SIG to address these 
issues and hopefully decide on a standard.  That way, I can at least 
implement patches in my app that will be compatible with whatever (if 
anything) is decided.

Thanks,
--nate

From david.lyon at preisshare.net  Wed Jan 13 00:56:34 2010
From: david.lyon at preisshare.net (David Lyon)
Date: Wed, 13 Jan 2010 10:56:34 +1100 (EST)
Subject: [Distutils] Platform naming standardization
In-Reply-To: <4B4CBA89.9020000@psu.edu>
References: <4B4CBA89.9020000@psu.edu>
Message-ID: <1393.218.214.45.58.1263340594.squirrel@syd-srv02.ezyreg.com>

> Hi,
>
> I'm involved with a software project that makes extensive use of third
> party modules with C extensions...
>
> setuptools uses distutils.util.get_platform() to ...
> ..
> ..
> It's not even crucial to me that these be fixed, but before I continue
> to hack up the platform string, I wanted to ask the SIG to address these
> issues and hopefully decide on a standard.  That way, I can at least
> implement patches in my app that will be compatible with whatever (if
> anything) is decided.

I think you are going to have to hack for now..

In fact, everyone is just having a good old hack at it..

distutils started as a hack.. and it is maybe getting cleaned
up now - but it was a hack for such a long time.

If you hack.. you'll be in good company. It's what everyone
is doing. You're on the right list.

:-)

> To ease installation, we pre-build
> them for some popular platforms and provide a distribution system for
> the app to fetch them.

very modern..

Can you divulge the name of your project? I'd like to
look at your hacking..

David



From ziade.tarek at gmail.com  Wed Jan 13 01:18:36 2010
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Wed, 13 Jan 2010 01:18:36 +0100
Subject: [Distutils] Platform naming standardization
In-Reply-To: <4B4CBA89.9020000@psu.edu>
References: <4B4CBA89.9020000@psu.edu>
Message-ID: <94bdd2611001121618n567ab6c3tff9f07ea532bb668@mail.gmail.com>

On Tue, Jan 12, 2010 at 7:08 PM, Nate Coraor <nate at psu.edu> wrote:
> Hi,
>
> I'm involved with a software project that makes extensive use of third party
> modules with C extensions. ?To ease installation, we pre-build them for some
> popular platforms and provide a distribution system for the app to fetch
> them.
>
> setuptools uses distutils.util.get_platform() to decide whether an egg found
> on the path is compatible, with some special extra magic added in for Mac OS
> X. ?Unfortunately, get_platform() as implemented does not provide enough
> information to ensure binary compatibility.

I think that this has to be discussed at Distutils/stdlib level.
Notice that I am currently in the
process of moving get_platform() out of Distutils, so it leaves in its
own module in the stdlib.

[..]
>
> It's not even crucial to me that these be fixed, but before I continue to
> hack up the platform string, I wanted to ask the SIG to address these issues
> and hopefully decide on a standard. ?That way, I can at least implement
> patches in my app that will be compatible with whatever (if anything) is
> decided.

Nothing has been decided yet on this. If you provide a patch for
get_platform() with a rational,
we can start the discussion here and work on a standard, we can then
bring it up at python-dev
once its ready.

Regards
Tarek

From ben+python at benfinney.id.au  Wed Jan 13 01:29:19 2010
From: ben+python at benfinney.id.au (Ben Finney)
Date: Wed, 13 Jan 2010 11:29:19 +1100
Subject: [Distutils] packaging terminology confusion
References: <4957f1ef1001070340y94da3cbgbc6dfe6c05028f3f@mail.gmail.com>
	<94bdd2611001071339g15942eb3rcf00dcb8ddd4ee5e@mail.gmail.com>
	<4B46576F.7070309@egenix.com>
	<4957f1ef1001071357y382db993qffaee3b5ba2277e2@mail.gmail.com>
	<4B465C5F.7030609@egenix.com>
	<94bdd2611001071422p56182196mb974e747a0adecd2@mail.gmail.com>
	<65e0bb521001071943n7bbf739au3f9c7fc9175c6d01@mail.gmail.com>
	<723929E9-9814-4005-9025-4F38355DB5E7@twistedmatrix.com>
	<3282.218.214.45.58.1263171427.squirrel@syd-srv02.ezyreg.com>
	<C0488BE7-A339-4D2B-B240-0BD1D71ECE79@python.org>
	<65e0bb521001110717i3f3b8941t1048eb71b2789686@mail.gmail.com>
	<1289.218.214.45.58.1263254993.squirrel@syd-srv02.ezyreg.com>
	<87k4voqf00.fsf@benfinney.id.au>
	<1640.218.214.45.58.1263260689.squirrel@syd-srv02.ezyreg.com>
Message-ID: <87my0iq23k.fsf@benfinney.id.au>

"David Lyon" <david.lyon at preisshare.net> writes:

> If you have a zip/archive file, you can put anything in it. No reason
> why 'everything' can't go in it.
>
> A "L'Oeuf incredible" might include a Python 2.x and Python 3.x code
> set, make code for linux, .pyd for windows.
>
> It would be so un-confusing to have an egg like that.

I disagree entirely with that last statement.

However, you're now talking about changing the package format, and not
the terminology of what we already have. So I'm dropping this
sub-thread.

-- 
 \            ?Simplicity is prerequisite for reliability.? ?Edsger W. |
  `\                                                          Dijkstra |
_o__)                                                                  |
Ben Finney


From david.lyon at preisshare.net  Wed Jan 13 01:46:58 2010
From: david.lyon at preisshare.net (David Lyon)
Date: Wed, 13 Jan 2010 11:46:58 +1100 (EST)
Subject: [Distutils] Platform naming standardization
In-Reply-To: <94bdd2611001121618n567ab6c3tff9f07ea532bb668@mail.gmail.com>
References: <4B4CBA89.9020000@psu.edu>
	<94bdd2611001121618n567ab6c3tff9f07ea532bb668@mail.gmail.com>
Message-ID: <1449.218.214.45.58.1263343618.squirrel@syd-srv02.ezyreg.com>


Hi Tarek,

i386 wrote:

>> setuptools uses distutils.util.get_platform() to decide whether an egg
>> found ..?Unfortunately, get_platform() .. compatibility.
>
> I think that this has to be discussed at Distutils/stdlib level.
> Notice that I am currently in the
> process of moving get_platform() out of Distutils, so it leaves in its
> own module in the stdlib.

But that only affects future users.

> Nothing has been decided yet on this. If you provide a patch for
> get_platform() with a rational,
> we can start the discussion here and work on a standard, we can then
> bring it up at python-dev once its ready.

I know you can patch python, that's easy for you. Not only that
but you are good at it.

The point Nate is making though is about better identifying
platforms to make build/installation decisions.

This use to be simple in metadata.. take a look...

-----------------------------------
Metadata-Version: 1.0
Name: tiddlyweb
Version: 0.9.96
Summary: An optionally headless, extensible RESTful datastore for
tiddlers: bits of stuff.
Home-page: http://pypi.python.org/pypi/tiddlyweb
Author: Chris Dent
Author-email: x at xxxxx
License: UNKNOWN
Description:
        TiddlyWeb Home Site: http://tiddlyweb.com/
        See also: http://tiddlywiki.org/wiki/TiddlyWeb
Platform: Posix; MacOS X; Windows
-----------------------------------

What Nate is requesting is specialised build
requirements on those particular operating systems.

In an easy to do manner. Without resorting to hacks.

My thoughts are starting to change for 2010. I want
Santa to bring me a new design for a build client for
Christmas.

I want it web based, I want to add my files. Do a
build with a nice graphic.

Maybe this new build tool won't even work under
python 2.x but only 3. I don't know.

I really wish you would start work on a new build
client so that we can all jump in and help you.

Just being realistic here. Patching distutils can
only go so far. Hacking with system api's can only
go so far.


David


















From david.lyon at preisshare.net  Wed Jan 13 01:51:56 2010
From: david.lyon at preisshare.net (David Lyon)
Date: Wed, 13 Jan 2010 11:51:56 +1100 (EST)
Subject: [Distutils] packaging terminology confusion
In-Reply-To: <87my0iq23k.fsf@benfinney.id.au>
References: <4957f1ef1001070340y94da3cbgbc6dfe6c05028f3f@mail.gmail.com>
	<94bdd2611001071339g15942eb3rcf00dcb8ddd4ee5e@mail.gmail.com>
	<4B46576F.7070309@egenix.com>
	<4957f1ef1001071357y382db993qffaee3b5ba2277e2@mail.gmail.com>
	<4B465C5F.7030609@egenix.com>
	<94bdd2611001071422p56182196mb974e747a0adecd2@mail.gmail.com>
	<65e0bb521001071943n7bbf739au3f9c7fc9175c6d01@mail.gmail.com>
	<723929E9-9814-4005-9025-4F38355DB5E7@twistedmatrix.com>
	<3282.218.214.45.58.1263171427.squirrel@syd-srv02.ezyreg.com>
	<C0488BE7-A339-4D2B-B240-0BD1D71ECE79@python.org>
	<65e0bb521001110717i3f3b8941t1048eb71b2789686@mail.gmail.com>
	<1289.218.214.45.58.1263254993.squirrel@syd-srv02.ezyreg.com>
	<87k4voqf00.fsf@benfinney.id.au>
	<1640.218.214.45.58.1263260689.squirrel@syd-srv02.ezyreg.com>
	<87my0iq23k.fsf@benfinney.id.au>
Message-ID: <1479.218.214.45.58.1263343916.squirrel@syd-srv02.ezyreg.com>

> Ben  writes:

> However, you're now talking about changing the package format, and not
> the terminology of what we already have. So I'm dropping this
> sub-thread.

ok - up to you. Don't talk about:

  http://www.python.org/dev/peps/pep-0376/

David



From cournape at gmail.com  Wed Jan 13 02:01:44 2010
From: cournape at gmail.com (David Cournapeau)
Date: Wed, 13 Jan 2010 10:01:44 +0900
Subject: [Distutils] Platform naming standardization
In-Reply-To: <4B4CBA89.9020000@psu.edu>
References: <4B4CBA89.9020000@psu.edu>
Message-ID: <5b8d13221001121701w36471ff5t53bb24fb7523653d@mail.gmail.com>

On Wed, Jan 13, 2010 at 3:08 AM, Nate Coraor <nate at psu.edu> wrote:

>
> It's not even crucial to me that these be fixed, but before I continue to
> hack up the platform string, I wanted to ask the SIG to address these issues
> and hopefully decide on a standard. ?That way, I can at least implement
> patches in my app that will be compatible with whatever (if anything) is
> decided.

I think the only reasonable approach today is to admit that python
does not have a well defined ABI (but see PEP 384), and only target
well known binary distributions. On mac os x, only target the python
from python.org, etc...

IMHO, all the attempts at distinguishing between UCS2 vs UCS4, etc...
are flawed, because that's only the tip of the iceberg, and it quickly
gives a big number of combinations. Cramming information into
get_platform to pretend it gives some kind of ABI guarantee does not
sound very robust.

cheers,

David

From zooko at zooko.com  Wed Jan 13 02:14:58 2010
From: zooko at zooko.com (Zooko Wilcox-O'Hearn)
Date: Tue, 12 Jan 2010 18:14:58 -0700
Subject: [Distutils] [Catalog-sig] packaging terminology confusion
In-Reply-To: <4957f1ef1001091047i661d79c1tfeb379386d95989a@mail.gmail.com>
References: <4957f1ef1001070340y94da3cbgbc6dfe6c05028f3f@mail.gmail.com>
	<65e0bb521001071943n7bbf739au3f9c7fc9175c6d01@mail.gmail.com>
	<4B46AD73.4000902@v.loewis.de> <20100108103539.20bd564c@freewill>
	<4B47547F.5090303@pangalactic.us>
	<319e029f1001080829w4a140dedr48e0d4dce249caed@mail.gmail.com>
	<4957f1ef1001080900h52f271ccg45f71f376592db79@mail.gmail.com>
	<20100108174506.B2C473A4074@sparrow.telecommunity.com>
	<4957f1ef1001090713l1ca97cd0k8254e9ed3ae4e34e@mail.gmail.com>
	<20100109163905.4671C3A4074@sparrow.telecommunity.com>
	<4957f1ef1001091047i661d79c1tfeb379386d95989a@mail.gmail.com>
Message-ID: <8DF189E4-24A5-427A-A003-15FFAF4032B8@zooko.com>

On Saturday, 2010-01-09, at 11:47 , Brad Allen wrote:

> Now I understand that your 'project' concept probably corresponds  
> to an entry in PyPI which is associated with multiple releases

Yep.  Or actually the "project" is the thing that a few hackers like  
to spend their time on.  It is the thing that evolves over time,  
endures forks and personnel changes, etc.  The page on PyPI is best  
understood as being the web page on PyPI which is here to inform you  
about the state of the project.

I tell people at hacker meetups that I work on the Tahoe-LAFS  
project.  They nod their heads.  I'm going to continue saying that,  
and they are going to continue nodding their heads, regardless of  
what we on this mailing list decide.

> When you have a release ready, what do you do with it? You  
> 'package' it, of course. You don't 'project' it, and you don't  
> 'parcel' it. What is the result of the 'packaging' activity? It's a  
> 'package' of course.

Bingo!  And, this is true regardless of whether you're working on a  
project written in Python or in another language or in a combination  
of languages.

> Maybe it's just wrong to call the __init__.py directories  
> 'packages', because they are really just a piece of what is getting  
> packaged.

Bingo!  A "package" is something that you deliver to someone else and  
they use it.  You don't deliver __init__.py directories to people.   
__init__.py directories are not packages.

Regards,

Zooko

From ziade.tarek at gmail.com  Wed Jan 13 02:18:18 2010
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Wed, 13 Jan 2010 02:18:18 +0100
Subject: [Distutils] Platform naming standardization
In-Reply-To: <5b8d13221001121701w36471ff5t53bb24fb7523653d@mail.gmail.com>
References: <4B4CBA89.9020000@psu.edu>
	<5b8d13221001121701w36471ff5t53bb24fb7523653d@mail.gmail.com>
Message-ID: <94bdd2611001121718p2e464d04jdac7ac32ef999503@mail.gmail.com>

On Wed, Jan 13, 2010 at 2:01 AM, David Cournapeau <cournape at gmail.com> wrote:
> On Wed, Jan 13, 2010 at 3:08 AM, Nate Coraor <nate at psu.edu> wrote:
>
>>
>> It's not even crucial to me that these be fixed, but before I continue to
>> hack up the platform string, I wanted to ask the SIG to address these issues
>> and hopefully decide on a standard. ?That way, I can at least implement
>> patches in my app that will be compatible with whatever (if anything) is
>> decided.
>
> I think the only reasonable approach today is to admit that python
> does not have a well defined ABI (but see PEP 384), and only target
> well known binary distributions. On mac os x, only target the python
> from python.org, etc...
>
> IMHO, all the attempts at distinguishing between UCS2 vs UCS4, etc...
> are flawed, because that's only the tip of the iceberg, and it quickly
> gives a big number of combinations. Cramming information into
> get_platform to pretend it gives some kind of ABI guarantee does not
> sound very robust.

Besides a well-defined ABI, if usc2/usc4 + 32/64 bits distinction on
some platforms
already fixes a numbers of use cases, I think could worth it for 2.7/3.2

From fuzzyman at gmail.com  Wed Jan 13 02:48:51 2010
From: fuzzyman at gmail.com (Michael)
Date: Wed, 13 Jan 2010 01:48:51 +0000
Subject: [Distutils] [Catalog-sig] packaging terminology confusion
In-Reply-To: <8DF189E4-24A5-427A-A003-15FFAF4032B8@zooko.com>
References: <4957f1ef1001070340y94da3cbgbc6dfe6c05028f3f@mail.gmail.com>
	<65e0bb521001071943n7bbf739au3f9c7fc9175c6d01@mail.gmail.com>
	<4B46AD73.4000902@v.loewis.de> <20100108103539.20bd564c@freewill>
	<4B47547F.5090303@pangalactic.us>
	<319e029f1001080829w4a140dedr48e0d4dce249caed@mail.gmail.com>
	<4957f1ef1001080900h52f271ccg45f71f376592db79@mail.gmail.com>
	<20100108174506.B2C473A4074@sparrow.telecommunity.com>
	<4957f1ef1001090713l1ca97cd0k8254e9ed3ae4e34e@mail.gmail.com>
	<20100109163905.4671C3A4074@sparrow.telecommunity.com>
	<4957f1ef1001091047i661d79c1tfeb379386d95989a@mail.gmail.com>
	<8DF189E4-24A5-427A-A003-15FFAF4032B8@zooko.com>
Message-ID: <316D5C2C-7B73-4CE3-8754-31BE0FA0B490@gmail.com>




--
http://www.ironpythoninaction.com

On 13 Jan 2010, at 01:14, Zooko Wilcox-O'Hearn <zooko at zooko.com> wrote:

>
>
>> When you have a release ready, what do you do with it? You  
>> 'package' it, of course. You don't 'project' it, and you don't  
>> 'parcel' it. What is the result of the 'packaging' activity? It's a  
>> 'package' of course.
>
> Bingo!  And, this is true regardless of whether you're working on a  
> project written in Python or in another language or in a combination  
> of languages.
>

That's just semantics - rephrase it a nd you get a different result.  
When you build a release are you building a package? No - you're  
building a release.

Michael




From jmg3000 at gmail.com  Wed Jan 13 04:18:10 2010
From: jmg3000 at gmail.com (John Gabriele)
Date: Tue, 12 Jan 2010 22:18:10 -0500
Subject: [Distutils] [Catalog-sig] packaging terminology confusion
In-Reply-To: <8DF189E4-24A5-427A-A003-15FFAF4032B8@zooko.com>
References: <4957f1ef1001070340y94da3cbgbc6dfe6c05028f3f@mail.gmail.com>
	<20100108103539.20bd564c@freewill> <4B47547F.5090303@pangalactic.us>
	<319e029f1001080829w4a140dedr48e0d4dce249caed@mail.gmail.com>
	<4957f1ef1001080900h52f271ccg45f71f376592db79@mail.gmail.com>
	<20100108174506.B2C473A4074@sparrow.telecommunity.com>
	<4957f1ef1001090713l1ca97cd0k8254e9ed3ae4e34e@mail.gmail.com>
	<20100109163905.4671C3A4074@sparrow.telecommunity.com>
	<4957f1ef1001091047i661d79c1tfeb379386d95989a@mail.gmail.com>
	<8DF189E4-24A5-427A-A003-15FFAF4032B8@zooko.com>
Message-ID: <65e0bb521001121918j1ea1018cye4074f76790ec248@mail.gmail.com>

On Tue, Jan 12, 2010 at 8:14 PM, Zooko Wilcox-O'Hearn <zooko at zooko.com> wrote:
> On Saturday, 2010-01-09, at 11:47 , Brad Allen wrote:
>
>> Now I understand that your 'project' concept probably corresponds to an
>> entry in PyPI which is associated with multiple releases
>
> Yep. ?Or actually the "project" is the thing that a few hackers like to
> spend their time on. ?It is the thing that evolves over time, endures forks
> and personnel changes, etc. ?The page on PyPI is best understood as being
> the web page on PyPI which is here to inform you about the state of the
> project.
>
> I tell people at hacker meetups that I work on the Tahoe-LAFS project. ?They
> nod their heads. ?I'm going to continue saying that, and they are going to
> continue nodding their heads, regardless of what we on this mailing list
> decide.
>
>> When you have a release ready, what do you do with it? You 'package' it,
>> of course. You don't 'project' it, and you don't 'parcel' it. What is the
>> result of the 'packaging' activity? It's a 'package' of course.
>
> Bingo! ?And, this is true regardless of whether you're working on a project
> written in Python or in another language or in a combination of languages.
>
>> Maybe it's just wrong to call the __init__.py directories 'packages',
>> because they are really just a piece of what is getting packaged.
>
> Bingo! ?A "package" is something that you deliver to someone else and they
> use it. ?You don't deliver __init__.py directories to people. ?__init__.py
> directories are not packages.
>

+1

If it were possible to rename "package" (the __init__.py kind), I
might suggest going with "battery", as in, "a whole battery of
modules".

( http://dictionary.reference.com/browse/battery )

Perhaps folks who run projects that distribute large numbers of
related packages/batteries could somehow distribute them together as
... oh, I dunno, ... a battery pack. :)

Also, fits well with "batteries included" motto. :)

http://python.org/images/batteries-included.jpg

---John

From nate at psu.edu  Wed Jan 13 04:27:25 2010
From: nate at psu.edu (Nate Coraor)
Date: Tue, 12 Jan 2010 22:27:25 -0500
Subject: [Distutils] Platform naming standardization
In-Reply-To: <94bdd2611001121618n567ab6c3tff9f07ea532bb668@mail.gmail.com>
References: <4B4CBA89.9020000@psu.edu>
	<94bdd2611001121618n567ab6c3tff9f07ea532bb668@mail.gmail.com>
Message-ID: <4B4D3D9D.3020505@psu.edu>

Tarek Ziad? wrote:

>> It's not even crucial to me that these be fixed, but before I continue to
>> hack up the platform string, I wanted to ask the SIG to address these issues
>> and hopefully decide on a standard.  That way, I can at least implement
>> patches in my app that will be compatible with whatever (if anything) is
>> decided.
> 
> Nothing has been decided yet on this. If you provide a patch for
> get_platform() with a rational,
> we can start the discussion here and work on a standard, we can then
> bring it up at python-dev
> once its ready.

I was holding off on creating such a patch until I had some input on 
what how the platform string should be constructed.  And indeed, from 
other messages in this thread it sounds like hacking up the platform 
string should not even be the way to do this.

I would be happy to provide something, though, if I should go ahead and 
come up with something that seems reasonable to me.

--nate

From ben+python at benfinney.id.au  Wed Jan 13 05:39:39 2010
From: ben+python at benfinney.id.au (Ben Finney)
Date: Wed, 13 Jan 2010 15:39:39 +1100
Subject: [Distutils] [Catalog-sig] packaging terminology confusion
References: <4957f1ef1001070340y94da3cbgbc6dfe6c05028f3f@mail.gmail.com>
	<65e0bb521001071943n7bbf739au3f9c7fc9175c6d01@mail.gmail.com>
	<4B46AD73.4000902@v.loewis.de> <20100108103539.20bd564c@freewill>
	<4B47547F.5090303@pangalactic.us>
	<319e029f1001080829w4a140dedr48e0d4dce249caed@mail.gmail.com>
	<4957f1ef1001080900h52f271ccg45f71f376592db79@mail.gmail.com>
	<20100108174506.B2C473A4074@sparrow.telecommunity.com>
	<4957f1ef1001090713l1ca97cd0k8254e9ed3ae4e34e@mail.gmail.com>
	<20100109163905.4671C3A4074@sparrow.telecommunity.com>
	<4957f1ef1001091047i661d79c1tfeb379386d95989a@mail.gmail.com>
	<8DF189E4-24A5-427A-A003-15FFAF4032B8@zooko.com>
Message-ID: <87iqb6pqic.fsf@benfinney.id.au>

Zooko Wilcox-O'Hearn <zooko at zooko.com> writes:

> On Saturday, 2010-01-09, at 11:47 , Brad Allen wrote:
> > Maybe it's just wrong to call the __init__.py directories packages',
> > because they are really just a piece of what is getting packaged.
>
> Bingo! A "package" is something that you deliver to someone else and
> they use it. You don't deliver __init__.py directories to people.
> __init__.py directories are not packages.

+1.

I think the above idea, of renaming Python's term for ?collection of
modules with a namespace?, is the most likely route to clearing up
confusion over the term ?package?. It is also the only option so far
presented that IMO has any hope of actually succeeding, since it's
addressing a Python-specific term.

Expecting the rest of the software community to treat the term ?package?
specially in the context of Python is futile. The term is established,
and Python's meaning conflicts with the established meaning.

We need distinct terms for both of these concepts, since they're both
involved in communications about distributing software. Until that
change happens, we can expect the confusion to continue indefinitely. I
hope no-one wants that.

-- 
 \         ?If you can do no good, at least do no harm.? ?_Slapstick_, |
  `\                                                     Kurt Vonnegut |
_o__)                                                                  |
Ben Finney


From david.lyon at preisshare.net  Wed Jan 13 06:54:55 2010
From: david.lyon at preisshare.net (David Lyon)
Date: Wed, 13 Jan 2010 16:54:55 +1100 (EST)
Subject: [Distutils] Platform naming standardization
In-Reply-To: <4B4D3D9D.3020505@psu.edu>
References: <4B4CBA89.9020000@psu.edu>
	<94bdd2611001121618n567ab6c3tff9f07ea532bb668@mail.gmail.com>
	<4B4D3D9D.3020505@psu.edu>
Message-ID: <2576.218.214.45.58.1263362095.squirrel@syd-srv02.ezyreg.com>

Nate wrote:

> It's not even crucial to me that these be fixed, but before I continue
> to hack up the platform string, I wanted to ask the SIG to address these
> issues and hopefully decide on a standard.  That way, I can at least
> implement patches in my app that will be compatible with whatever (if
> anything) is decided.

Some discussion on ways to achieve different builds was done last
year. Lots of things were discussed and a few decisions.

I fear the wrong decision about platform naming standardization
is going to be made with PEP-345. That is, abandoning traditional
description via metadata, and replacing it with the ability to
embed python sub-system hacks. It's cheap. And disrespects prior
Python Metadata art.

Already in Python Metadata, there's a wealth of platform information
that could be used and extended to make decisions on platform
conditional builds.

Thus helping to solve your particular problem.

For example, look for the "Platform:" keyword below..

---------------------------------------------------
Metadata-Version: 1.0
Name: tiddlyweb
Version: 0.9.96
bits of stuff.
Home-page: http://pypi.python.org/pypi/tiddlyweb
Author: Chris Dent
Description:
        TiddlyWeb Home Site: http://tiddlyweb.com/
        See also: http://tiddlywiki.org/wiki/TiddlyWeb

        For installation instructions see http://tiddlyweb.peermore.com/
        ....
Platform: Posix; MacOS X; Windows
---------------------------------------------------

Those constants could be extended or reused to do conditional
builds.

For example, in a setup.cfg, specify:

[Build Posix]
command=buildit.sh

[Build MacOS X]
command=buildosx.sh

[Build Windows]
command=buildw.bat

Unfortunately, the guys who make the decisions on the PEPs
don't seem to want to extend this way. Perhaps because they
(wrongly) think it might lead to a bikeshed. I can't see
how it would.

This to me (existing art), makes sense:

 >  Platform: Posix; MacOS X; Windows

Not using these terms and resorting to i386 for mac and
x86 or i686 for Windows is really strange. We had everything
right there in front of us before.

Anyway...

I looked through Galaxy, and there is no setup.py file.

So I think an installation could be totally achievable
with via a modified Metadata file looking like this:

----------------------------------------------------
 > Name: Galaxy
 > Home-page: http://bitbucket.org/galaxy/
 > Source-Repository: hg:http://bitbucket.org/galaxy/galaxy-dist/
 > Platform: Posix; MacOS X
----------------------------------------------------

and a setup.cfg looking like this:

----------------------------------------------------
[postinstall]
script = run.sh
----------------------------------------------------

I wish I could say that I had it working today. I don't
unfortunately. I've been trying to learn the mercurial
api for checking it out etc etc. I'm a humble hacker
doing this for my own enjoyment. And getting paid
50 ruppies from work too.

But a whole install of a package as complex as Galaxy
impwo could quite easily be done by pushing all the hard
work back to mercurial. Then chaining of to your run.sh
at the end.

My hacking has started on
http://bitbucket.org/djlyon/original-setup.py-with-metadata/src/tip/install_from_pkginfo.py

So there's some way to go...

Regards

David





From cournape at gmail.com  Wed Jan 13 07:17:25 2010
From: cournape at gmail.com (David Cournapeau)
Date: Wed, 13 Jan 2010 15:17:25 +0900
Subject: [Distutils] Platform naming standardization
In-Reply-To: <94bdd2611001121718p2e464d04jdac7ac32ef999503@mail.gmail.com>
References: <4B4CBA89.9020000@psu.edu>
	<5b8d13221001121701w36471ff5t53bb24fb7523653d@mail.gmail.com>
	<94bdd2611001121718p2e464d04jdac7ac32ef999503@mail.gmail.com>
Message-ID: <5b8d13221001122217k51d255f6tc6fa21f57cd97545@mail.gmail.com>

On Wed, Jan 13, 2010 at 10:18 AM, Tarek Ziad? <ziade.tarek at gmail.com> wrote:

>
> Besides a well-defined ABI, if usc2/usc4 + 32/64 bits distinction on
> some platforms
> already fixes a numbers of use cases, I think could worth it for 2.7/3.2

What bothers me is that get_platform is the wrong function for this -
it is also likely that changing its behavior may break existing
extensions and build scripts (as get_platform is used to generate some
"distributions" names).

If a function to qualify an ABI on a specific platform is needed, it
should be a new function IMHO.

cheers,

David

From chris at simplistix.co.uk  Wed Jan 13 09:08:48 2010
From: chris at simplistix.co.uk (Chris Withers)
Date: Wed, 13 Jan 2010 08:08:48 +0000
Subject: [Distutils] Platform naming standardization
In-Reply-To: <5b8d13221001122217k51d255f6tc6fa21f57cd97545@mail.gmail.com>
References: <4B4CBA89.9020000@psu.edu>	<5b8d13221001121701w36471ff5t53bb24fb7523653d@mail.gmail.com>	<94bdd2611001121718p2e464d04jdac7ac32ef999503@mail.gmail.com>
	<5b8d13221001122217k51d255f6tc6fa21f57cd97545@mail.gmail.com>
Message-ID: <4B4D7F90.1060205@simplistix.co.uk>

David Cournapeau wrote:
> If a function to qualify an ABI on a specific platform is needed, it
> should be a new function IMHO.

+1, but I do think that this new function should provide the level of 
detail that Nate is asking for.

cheers,

Chris

-- 
Simplistix - Content Management, Batch Processing & Python Consulting
            - http://www.simplistix.co.uk

From chris at simplistix.co.uk  Wed Jan 13 09:18:47 2010
From: chris at simplistix.co.uk (Chris Withers)
Date: Wed, 13 Jan 2010 08:18:47 +0000
Subject: [Distutils] buildout config question
In-Reply-To: <118246c11001091501r2ac46367je763ce08ec6f9d1b@mail.gmail.com>
References: <118246c11001091501r2ac46367je763ce08ec6f9d1b@mail.gmail.com>
Message-ID: <4B4D81E7.10005@simplistix.co.uk>

Olaf Conradi wrote:
> [bank2ledger]
> recipe = zc.recipe.egg:scripts
> eggs =
>     bank2ledger
>     pyxdg
> 
> [pylint]
> recipe = zc.recipe.egg
> eggs =
>     pylint
>     ${bank2ledger:eggs}
> entry-points = pylint=pylint.lint:Run
> arguments = sys.argv[1:]+[
>     '--output-format=parseable',
>     'bank2ledger']

Both of these sections generate a bin/bank2ledger script.
This is an error, and one that buildout should likely complain about.

You need to arrange for one of them to have a different name.
zc.recipe.egg may have a way to support that, check the docs and let us 
know what you find.

cheers,

Chris

-- 
Simplistix - Content Management, Batch Processing & Python Consulting
            - http://www.simplistix.co.uk

From ziade.tarek at gmail.com  Wed Jan 13 09:47:35 2010
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Wed, 13 Jan 2010 09:47:35 +0100
Subject: [Distutils] Platform naming standardization
In-Reply-To: <5b8d13221001122217k51d255f6tc6fa21f57cd97545@mail.gmail.com>
References: <4B4CBA89.9020000@psu.edu>
	<5b8d13221001121701w36471ff5t53bb24fb7523653d@mail.gmail.com>
	<94bdd2611001121718p2e464d04jdac7ac32ef999503@mail.gmail.com>
	<5b8d13221001122217k51d255f6tc6fa21f57cd97545@mail.gmail.com>
Message-ID: <94bdd2611001130047x48417f5ek75cc3946834be747@mail.gmail.com>

On Wed, Jan 13, 2010 at 7:17 AM, David Cournapeau <cournape at gmail.com> wrote:
> On Wed, Jan 13, 2010 at 10:18 AM, Tarek Ziad? <ziade.tarek at gmail.com> wrote:
>
>>
>> Besides a well-defined ABI, if usc2/usc4 + 32/64 bits distinction on
>> some platforms
>> already fixes a numbers of use cases, I think could worth it for 2.7/3.2
>
> What bothers me is that get_platform is the wrong function for this -
> it is also likely that changing its behavior may break existing
> extensions and build scripts (as get_platform is used to generate some
> "distributions" names).
>
> If a function to qualify an ABI on a specific platform is needed, it
> should be a new function IMHO.
>

I had a backward compatible mode in mind, maybe with a boolean option
like "detailed".
Because at the end, If i understand the need correctly, it will be
used where get_platform()
is used today


>
> David
>



-- 
Tarek Ziad? | http://ziade.org

From cournape at gmail.com  Wed Jan 13 09:59:42 2010
From: cournape at gmail.com (David Cournapeau)
Date: Wed, 13 Jan 2010 17:59:42 +0900
Subject: [Distutils] Platform naming standardization
In-Reply-To: <94bdd2611001130047x48417f5ek75cc3946834be747@mail.gmail.com>
References: <4B4CBA89.9020000@psu.edu>
	<5b8d13221001121701w36471ff5t53bb24fb7523653d@mail.gmail.com>
	<94bdd2611001121718p2e464d04jdac7ac32ef999503@mail.gmail.com>
	<5b8d13221001122217k51d255f6tc6fa21f57cd97545@mail.gmail.com>
	<94bdd2611001130047x48417f5ek75cc3946834be747@mail.gmail.com>
Message-ID: <5b8d13221001130059i7025f0e0rea3821b834ad5f12@mail.gmail.com>

On Wed, Jan 13, 2010 at 5:47 PM, Tarek Ziad? <ziade.tarek at gmail.com> wrote:

> Because at the end, If i understand the need correctly, it will be
> used where get_platform()
> is used today

I don't think that's true - get_platform only returns the platform. It
has been used for ABI check by accident, and if you look at the
current distutils documentation, nothings hints about ABI
compatibility issues. Certainly, the *concepts* of platform (as
described in distutils doc) and ABI have nothing to do with each
other.

As for what the hypothetical function, it should at least contain the
python version, UCS 2 vs 4, debug vs release vs other special builds
(which are all incompatible with each other, at least on some
platforms), the C runtime you link against, the compiler, etc... Just
to cite what causes trouble in numpy's case - and I don't see why any
sufficiently complicated C extension would not have the same kind of
issues.

cheers,

David

From oekopez at gmx.de  Wed Jan 13 12:34:04 2010
From: oekopez at gmx.de (oekopez at gmx.de)
Date: Wed, 13 Jan 2010 12:34:04 +0100
Subject: [Distutils] mingw32 linker does not find the file lib_*.a
Message-ID: <20100113113404.4740@gmx.net>

Hi,

I've got a problem using mingw32 (gcc 4.4.0) with distutils for my extension module.
The error message appears in the linking step:

g++: build\temp.win32-2.6\Release\.\cmf\cmf_core_src\lib_cmf_core.a: No such file or directory

Which is puzzling me, since lib_cmf_core.a should be build by --output-lib alongside to _cmf_core.pyd. Compiling with VS2008 works fine. 
Christian K. posted the same problem 2 years ago in the thread "[Distutils] errors compiling c++ extensions with swig on windows" (my extension is wrapped by swig also) but never got an answer. 
Does anybody know by now how to deal with this problem?

Philipp
-- 
Preisknaller: GMX DSL Flatrate f?r nur 16,99 Euro/mtl.!
http://portal.gmx.net/de/go/dsl02

From jim at zope.com  Wed Jan 13 13:44:40 2010
From: jim at zope.com (Jim Fulton)
Date: Wed, 13 Jan 2010 07:44:40 -0500
Subject: [Distutils] buildout config question
In-Reply-To: <4B4D81E7.10005@simplistix.co.uk>
References: <118246c11001091501r2ac46367je763ce08ec6f9d1b@mail.gmail.com>
	<4B4D81E7.10005@simplistix.co.uk>
Message-ID: <1099b90b1001130444w2ab8d1f8u8f63ca9f6d2f548d@mail.gmail.com>

On Wed, Jan 13, 2010 at 3:18 AM, Chris Withers <chris at simplistix.co.uk> wrote:

Thanks for responding.

> Olaf Conradi wrote:
>>
>> [bank2ledger]
>> recipe = zc.recipe.egg:scripts
>> eggs =
>> ? ?bank2ledger
>> ? ?pyxdg
>>
>> [pylint]
>> recipe = zc.recipe.egg
>> eggs =
>> ? ?pylint
>> ? ?${bank2ledger:eggs}
>> entry-points = pylint=pylint.lint:Run
>> arguments = sys.argv[1:]+[
>> ? ?'--output-format=parseable',
>> ? ?'bank2ledger']
>
> Both of these sections generate a bin/bank2ledger script.

Yup.

> This is an error, and one that buildout should likely complain about.

I don't consider it an error. I often override a script generated by another
part.

I can see benefit in buildout saying something about this situation.

> You need to arrange for one of them to have a different name.
> zc.recipe.egg may have a way to support that, check the docs and let us know
> what you find.

Yup.  http://pypi.python.org/pypi/zc.recipe.egg#controlling-script-generation

Jim

-- 
Jim Fulton

From mal at egenix.com  Wed Jan 13 16:15:02 2010
From: mal at egenix.com (M.-A. Lemburg)
Date: Wed, 13 Jan 2010 16:15:02 +0100
Subject: [Distutils] Platform naming standardization
In-Reply-To: <4B4CBA89.9020000@psu.edu>
References: <4B4CBA89.9020000@psu.edu>
Message-ID: <4B4DE376.5030108@egenix.com>

Nate Coraor wrote:
> Hi,
> 
> I'm involved with a software project that makes extensive use of third
> party modules with C extensions.  To ease installation, we pre-build
> them for some popular platforms and provide a distribution system for
> the app to fetch them.
> 
> setuptools uses distutils.util.get_platform() to decide whether an egg
> found on the path is compatible, with some special extra magic added in
> for Mac OS X.  Unfortunately, get_platform() as implemented does not
> provide enough information to ensure binary compatibility.

I'm not sure whether fixing get_platform() is the right approach -
you are mostly talking about different ways to build Python. This
API is used (and misused) in a lot of ways, so it's probably
better to just create a new API for returning a combined platform
and Python version string that correctly identifies the various
possible combinations.

All the required information is available via the platform
module APIs.

Some comments:

> Among the platforms we use, these are the issues:
> 
> 1) On all platforms, interpreters compiled with UCS2 and UCS4 are binary
> incompatible, so modules compiled on one will fail to import on the
> other.  We work around this by appending -ucsX to the platform string,
> based on the value of sys.maxunicode.

Indeed. This is a major Python property completely ignored by setuptools.

> 2) On OS X, the modification to the value returned by
> pkg_resources.get_platform() isn't correct for fat version of Python
> 2.5, as detailed in setuptools issue 19.  To solve that, we're using the
> patch I submitted to the issue (with a couple recent changes).

I think that using "fat" in the version string is wrong for
Mac OS X, since there are many ways to build fat binaries.

Instead, the version string should include the details of
all included builds, ie. 'x86', 'x64', 'ppc', 'ppc64'.

> 3) On Solaris (and likely other UNIXes where 32 and 64 bit user spaces
> coexist), no distinction is made between a 32 bit and 64 bit
> interpreter, and they are not binary compatible.  We work around this by
> checking sys.maxint, and right now in testing I'm appending -32 or -64
> to the platform string (but before -ucsX).  I haven't settled on this,
> though, since I have a feeling maybe it should be part of the arch
> (sun4u_32, i86pc_64, etc.) or something like 'solaris32' and 'solaris64'
> instead of 'solaris'.

Both the processor type and 32/64-bit type are important to
have in the string.

> 4) Also on Solaris, the OS is binary compatible with older releases, so
> Solaris binary distributors will often build on the oldest reasonable
> release.  This is not possible with setuptools now, although extending
> pkg_resources.compatible_platforms() in pretty much the same manner as
> is done for OS X solves this (and I can provide a patch).

Ideally, distutils or platform should provide both an API
to create a standard Python and platform identification string
as well as an API to check the runtime values against a given
string read from e.g. an egg index, ie.

platform.get_distribution_platform()
platform.compare_distribution_platform()

> It's not even crucial to me that these be fixed, but before I continue
> to hack up the platform string, I wanted to ask the SIG to address these
> issues and hopefully decide on a standard.  That way, I can at least
> implement patches in my app that will be compatible with whatever (if
> anything) is decided.

Since most of the issues are with setuptools and/or distribute,
it's probably better to ask there.

Python eggs with C extensions don't really work well on Unix
platforms due to the above restrictions.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Jan 13 2010)
>>> Python/Zope Consulting and Support ...        http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ...             http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...        http://python.egenix.com/
________________________________________________________________________

::: Try our new mxODBC.Connect Python Database Interface for free ! ::::


   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
    D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
           Registered at Amtsgericht Duesseldorf: HRB 46611
               http://www.egenix.com/company/contact/

From mal at egenix.com  Wed Jan 13 18:41:18 2010
From: mal at egenix.com (M.-A. Lemburg)
Date: Wed, 13 Jan 2010 18:41:18 +0100
Subject: [Distutils] Platform naming standardization
In-Reply-To: <115628741786360745376315588794785737544-Webmail@me.com>
References: <4B4CBA89.9020000@psu.edu> <4B4DE376.5030108@egenix.com>
	<115628741786360745376315588794785737544-Webmail@me.com>
Message-ID: <4B4E05BE.3000703@egenix.com>

Ronald Oussoren wrote:
>  
> On Wednesday, January 13, 2010, at 04:15PM, "M.-A. Lemburg" <mal at egenix.com> wrote:
> 
>>
>>> 2) On OS X, the modification to the value returned by
>>> pkg_resources.get_platform() isn't correct for fat version of Python
>>> 2.5, as detailed in setuptools issue 19.  To solve that, we're using the
>>> patch I submitted to the issue (with a couple recent changes).
>>
>> I think that using "fat" in the version string is wrong for
>> Mac OS X, since there are many ways to build fat binaries.
>>
>> Instead, the version string should include the details of
>> all included builds, ie. 'x86', 'x64', 'ppc', 'ppc64'.
> 
> Maybe in the long run, but for now "fat" has a well-defined meaning for distutils: fat == ppc + x86_64. There is also a number of other variants, as described in the documentation for distutils.

I think you meant: fat == ppc + i386.

However, it's also possible to build binaries with ppc, i386 and
x86_64 - as are shipped with Mac OS X 10.6, so "fat" is not really
well-defined and could lead to trying to install 32-bit software for
a 64-bit build of Python.

IMHO, it's better to list the actually supported architectures
as e.g. "darwin-i386-ppc" or "darwin-i386-ppc-x86_64".

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Jan 13 2010)
>>> Python/Zope Consulting and Support ...        http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ...             http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...        http://python.egenix.com/
________________________________________________________________________

::: Try our new mxODBC.Connect Python Database Interface for free ! ::::


   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
    D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
           Registered at Amtsgericht Duesseldorf: HRB 46611
               http://www.egenix.com/company/contact/

From ronaldoussoren at mac.com  Wed Jan 13 17:46:39 2010
From: ronaldoussoren at mac.com (Ronald Oussoren)
Date: Wed, 13 Jan 2010 17:46:39 +0100
Subject: [Distutils] Platform naming standardization
In-Reply-To: <4B4DE376.5030108@egenix.com>
References: <4B4CBA89.9020000@psu.edu> <4B4DE376.5030108@egenix.com>
Message-ID: <115628741786360745376315588794785737544-Webmail@me.com>

 
On Wednesday, January 13, 2010, at 04:15PM, "M.-A. Lemburg" <mal at egenix.com> wrote:

>
>> 2) On OS X, the modification to the value returned by
>> pkg_resources.get_platform() isn't correct for fat version of Python
>> 2.5, as detailed in setuptools issue 19.  To solve that, we're using the
>> patch I submitted to the issue (with a couple recent changes).
>
>I think that using "fat" in the version string is wrong for
>Mac OS X, since there are many ways to build fat binaries.
>
>Instead, the version string should include the details of
>all included builds, ie. 'x86', 'x64', 'ppc', 'ppc64'.

Maybe in the long run, but for now "fat" has a well-defined meaning for distutils: fat == ppc + x86_64. There is also a number of other variants, as described in the documentation for distutils.

Ronald

From martin at v.loewis.de  Wed Jan 13 20:34:37 2010
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Wed, 13 Jan 2010 20:34:37 +0100
Subject: [Distutils] mingw32 linker does not find the file lib_*.a
In-Reply-To: <20100113113404.4740@gmx.net>
References: <20100113113404.4740@gmx.net>
Message-ID: <4B4E204D.9070807@v.loewis.de>

> Does anybody know by now how to deal with this problem?

I don't - but can you please post the complete trace of
all commands invoked in the build process?

Regards,
Martin

From ronaldoussoren at mac.com  Wed Jan 13 21:20:15 2010
From: ronaldoussoren at mac.com (Ronald Oussoren)
Date: Wed, 13 Jan 2010 21:20:15 +0100
Subject: [Distutils] Platform naming standardization
In-Reply-To: <4B4E05BE.3000703@egenix.com>
References: <4B4CBA89.9020000@psu.edu> <4B4DE376.5030108@egenix.com>
	<115628741786360745376315588794785737544-Webmail@me.com>
	<4B4E05BE.3000703@egenix.com>
Message-ID: <22F99734-448F-4CB7-90CF-974A8F27EBE4@mac.com>


On 13 Jan, 2010, at 18:41, M.-A. Lemburg wrote:

> Ronald Oussoren wrote:
>> 
>> On Wednesday, January 13, 2010, at 04:15PM, "M.-A. Lemburg" <mal at egenix.com> wrote:
>> 
>>> 
>>>> 2) On OS X, the modification to the value returned by
>>>> pkg_resources.get_platform() isn't correct for fat version of Python
>>>> 2.5, as detailed in setuptools issue 19.  To solve that, we're using the
>>>> patch I submitted to the issue (with a couple recent changes).
>>> 
>>> I think that using "fat" in the version string is wrong for
>>> Mac OS X, since there are many ways to build fat binaries.
>>> 
>>> Instead, the version string should include the details of
>>> all included builds, ie. 'x86', 'x64', 'ppc', 'ppc64'.
>> 
>> Maybe in the long run, but for now "fat" has a well-defined meaning for distutils: fat == ppc + x86_64. There is also a number of other variants, as described in the documentation for distutils.
> 
> I think you meant: fat == ppc + i386.

Thats right.
> 
> However, it's also possible to build binaries with ppc, i386 and
> x86_64 - as are shipped with Mac OS X 10.6, so "fat" is not really
> well-defined and could lead to trying to install 32-bit software for
> a 64-bit build of Python.

"fat" is well-defined for distutils, see the definition of get_platform at <http://docs.python.org/distutils/apiref.html>. 

For distutils "fat" is always a universal binary with architectures i386 and ppc, with alternate names for other variants.

> 
> IMHO, it's better to list the actually supported architectures
> as e.g. "darwin-i386-ppc" or "darwin-i386-ppc-x86_64".

That is not how distutils currently works. I also object to "darwin" as a prefix, the platform is named "macosx". Darwin is the opensource unix variant used in OSX and that name shouldn't be interchangeably with macosx.  I'm also unhappy that sys.platform is "darwin" on OSX, but it's probably too late to change that.

Ronald
> 
> -- 
> Marc-Andre Lemburg
> eGenix.com
> 
> Professional Python Services directly from the Source  (#1, Jan 13 2010)
>>>> Python/Zope Consulting and Support ...        http://www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ...             http://zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ...        http://python.egenix.com/
> ________________________________________________________________________
> 
> ::: Try our new mxODBC.Connect Python Database Interface for free ! ::::
> 
> 
>   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
>    D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
>           Registered at Amtsgericht Duesseldorf: HRB 46611
>               http://www.egenix.com/company/contact/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3567 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20100113/65879e8e/attachment.bin>

From mal at egenix.com  Wed Jan 13 23:44:22 2010
From: mal at egenix.com (M.-A. Lemburg)
Date: Wed, 13 Jan 2010 23:44:22 +0100
Subject: [Distutils] Platform naming standardization
In-Reply-To: <22F99734-448F-4CB7-90CF-974A8F27EBE4@mac.com>
References: <4B4CBA89.9020000@psu.edu>
	<4B4DE376.5030108@egenix.com>	<115628741786360745376315588794785737544-Webmail@me.com>	<4B4E05BE.3000703@egenix.com>
	<22F99734-448F-4CB7-90CF-974A8F27EBE4@mac.com>
Message-ID: <4B4E4CC6.8070902@egenix.com>

Ronald Oussoren wrote:
> 
> On 13 Jan, 2010, at 18:41, M.-A. Lemburg wrote:
> 
>> Ronald Oussoren wrote:
>>>
>>> On Wednesday, January 13, 2010, at 04:15PM, "M.-A. Lemburg" <mal at egenix.com> wrote:
>>>
>>>>
>>>>> 2) On OS X, the modification to the value returned by
>>>>> pkg_resources.get_platform() isn't correct for fat version of Python
>>>>> 2.5, as detailed in setuptools issue 19.  To solve that, we're using the
>>>>> patch I submitted to the issue (with a couple recent changes).
>>>>
>>>> I think that using "fat" in the version string is wrong for
>>>> Mac OS X, since there are many ways to build fat binaries.
>>>>
>>>> Instead, the version string should include the details of
>>>> all included builds, ie. 'x86', 'x64', 'ppc', 'ppc64'.
>>>
>>> Maybe in the long run, but for now "fat" has a well-defined meaning for distutils: fat == ppc + x86_64. There is also a number of other variants, as described in the documentation for distutils.
>>
>> I think you meant: fat == ppc + i386.
> 
> Thats right.
>>
>> However, it's also possible to build binaries with ppc, i386 and
>> x86_64 - as are shipped with Mac OS X 10.6, so "fat" is not really
>> well-defined and could lead to trying to install 32-bit software for
>> a 64-bit build of Python.
> 
> "fat" is well-defined for distutils, see the definition of get_platform at <http://docs.python.org/distutils/apiref.html>. 
> 
> For distutils "fat" is always a universal binary with architectures i386 and ppc, with alternate names for other variants.

Thanks for pointing that out, however, I don't think that creating
aliases for combinations of various different architectures
is a good idea.

It's better to make the included architectures explicit and use
this logic for all platforms, not just Mac OS X.

>> IMHO, it's better to list the actually supported architectures
>> as e.g. "darwin-i386-ppc" or "darwin-i386-ppc-x86_64".
> 
> That is not how distutils currently works. I also object to "darwin" as a prefix, the platform is named "macosx". Darwin is the opensource unix variant used in OSX and that name shouldn't be interchangeably with macosx.  I'm also unhappy that sys.platform is "darwin" on OSX, but it's probably too late to change that.

"Darwin" is what Mac OS X itself returns as "uname -s" and that's
generally what's being used for sys.platform on Unix systems (configure
sets MACHDEP which then gets transmogrified into PLATFORM which then
is fed to Py_GetPlatform() which then gets exposed as sys.platform
- just wrote that down here, since I just spent half an hour trying
to find the definition of PLATFORM...).

I agree, though, that the marketing names of the OSes are
somewhat more intuitive :-)

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Jan 13 2010)
>>> Python/Zope Consulting and Support ...        http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ...             http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...        http://python.egenix.com/
________________________________________________________________________

::: Try our new mxODBC.Connect Python Database Interface for free ! ::::


   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
    D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
           Registered at Amtsgericht Duesseldorf: HRB 46611
               http://www.egenix.com/company/contact/

From ronaldoussoren at mac.com  Thu Jan 14 08:08:09 2010
From: ronaldoussoren at mac.com (Ronald Oussoren)
Date: Thu, 14 Jan 2010 08:08:09 +0100
Subject: [Distutils] Platform naming standardization
In-Reply-To: <4B4E4CC6.8070902@egenix.com>
References: <4B4CBA89.9020000@psu.edu> <4B4DE376.5030108@egenix.com>
	<115628741786360745376315588794785737544-Webmail@me.com>
	<4B4E05BE.3000703@egenix.com>
	<22F99734-448F-4CB7-90CF-974A8F27EBE4@mac.com>
	<4B4E4CC6.8070902@egenix.com>
Message-ID: <A8E9DF44-D891-4A18-B910-DC204D55117C@mac.com>


On 13 Jan, 2010, at 23:44, M.-A. Lemburg wrote:

> Ronald Oussoren wrote:
>> 
>> On 13 Jan, 2010, at 18:41, M.-A. Lemburg wrote:
>> 
>>> Ronald Oussoren wrote:
>>>> 
>>>> On Wednesday, January 13, 2010, at 04:15PM, "M.-A. Lemburg" <mal at egenix.com> wrote:
>>>> 
>>>>> 
>>>>>> 2) On OS X, the modification to the value returned by
>>>>>> pkg_resources.get_platform() isn't correct for fat version of Python
>>>>>> 2.5, as detailed in setuptools issue 19.  To solve that, we're using the
>>>>>> patch I submitted to the issue (with a couple recent changes).
>>>>> 
>>>>> I think that using "fat" in the version string is wrong for
>>>>> Mac OS X, since there are many ways to build fat binaries.
>>>>> 
>>>>> Instead, the version string should include the details of
>>>>> all included builds, ie. 'x86', 'x64', 'ppc', 'ppc64'.
>>>> 
>>>> Maybe in the long run, but for now "fat" has a well-defined meaning for distutils: fat == ppc + x86_64. There is also a number of other variants, as described in the documentation for distutils.
>>> 
>>> I think you meant: fat == ppc + i386.
>> 
>> Thats right.
>>> 
>>> However, it's also possible to build binaries with ppc, i386 and
>>> x86_64 - as are shipped with Mac OS X 10.6, so "fat" is not really
>>> well-defined and could lead to trying to install 32-bit software for
>>> a 64-bit build of Python.
>> 
>> "fat" is well-defined for distutils, see the definition of get_platform at <http://docs.python.org/distutils/apiref.html>. 
>> 
>> For distutils "fat" is always a universal binary with architectures i386 and ppc, with alternate names for other variants.
> 
> Thanks for pointing that out, however, I don't think that creating
> aliases for combinations of various different architectures
> is a good idea.
> 
> It's better to make the included architectures explicit and use
> this logic for all platforms, not just Mac OS X.

I would probably have done that, knowing what I know now.   

Hashing out the details on what combinations of architectures are valid during installation will be fun though ;-). That is, if my python says its machine is "i386,x86_64" is it then acceptable to install an "i386" binary, an "i386,x86_64" binary, and "i386,ppc, x86_64" binary?

Ronald
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3567 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20100114/870ce9a1/attachment-0001.bin>

From mal at egenix.com  Thu Jan 14 10:36:46 2010
From: mal at egenix.com (M.-A. Lemburg)
Date: Thu, 14 Jan 2010 10:36:46 +0100
Subject: [Distutils] Platform naming standardization
In-Reply-To: <A8E9DF44-D891-4A18-B910-DC204D55117C@mac.com>
References: <4B4CBA89.9020000@psu.edu>
	<4B4DE376.5030108@egenix.com>	<115628741786360745376315588794785737544-Webmail@me.com>	<4B4E05BE.3000703@egenix.com>	<22F99734-448F-4CB7-90CF-974A8F27EBE4@mac.com>	<4B4E4CC6.8070902@egenix.com>
	<A8E9DF44-D891-4A18-B910-DC204D55117C@mac.com>
Message-ID: <4B4EE5AE.20106@egenix.com>

Ronald Oussoren wrote:
> 
> On 13 Jan, 2010, at 23:44, M.-A. Lemburg wrote:
> 
>> Ronald Oussoren wrote:
>>>
>>> On 13 Jan, 2010, at 18:41, M.-A. Lemburg wrote:
>>>
>>>> Ronald Oussoren wrote:
>>>>>
>>>>> On Wednesday, January 13, 2010, at 04:15PM, "M.-A. Lemburg" <mal at egenix.com> wrote:
>>>>>
>>>>>>
>>>>>>> 2) On OS X, the modification to the value returned by
>>>>>>> pkg_resources.get_platform() isn't correct for fat version of Python
>>>>>>> 2.5, as detailed in setuptools issue 19.  To solve that, we're using the
>>>>>>> patch I submitted to the issue (with a couple recent changes).
>>>>>>
>>>>>> I think that using "fat" in the version string is wrong for
>>>>>> Mac OS X, since there are many ways to build fat binaries.
>>>>>>
>>>>>> Instead, the version string should include the details of
>>>>>> all included builds, ie. 'x86', 'x64', 'ppc', 'ppc64'.
>>>>>
>>>>> Maybe in the long run, but for now "fat" has a well-defined meaning for distutils: fat == ppc + x86_64. There is also a number of other variants, as described in the documentation for distutils.
>>>>
>>>> I think you meant: fat == ppc + i386.
>>>
>>> Thats right.
>>>>
>>>> However, it's also possible to build binaries with ppc, i386 and
>>>> x86_64 - as are shipped with Mac OS X 10.6, so "fat" is not really
>>>> well-defined and could lead to trying to install 32-bit software for
>>>> a 64-bit build of Python.
>>>
>>> "fat" is well-defined for distutils, see the definition of get_platform at <http://docs.python.org/distutils/apiref.html>. 
>>>
>>> For distutils "fat" is always a universal binary with architectures i386 and ppc, with alternate names for other variants.
>>
>> Thanks for pointing that out, however, I don't think that creating
>> aliases for combinations of various different architectures
>> is a good idea.
>>
>> It's better to make the included architectures explicit and use
>> this logic for all platforms, not just Mac OS X.
> 
> I would probably have done that, knowing what I know now.   
> 
> Hashing out the details on what combinations of architectures are valid during installation will be fun though ;-). That is, if my python says its machine is "i386,x86_64" is it then acceptable to install an "i386" binary, an "i386,x86_64" binary, and "i386,ppc, x86_64" binary?

The point is that even though your Python binary may say it's
"i386,x86_64", the version you run your application with
will either be "i386" or "x86_64" (depending on the OS environment
settings).

Now let's say you're running the "i386" version. As long as all
installed components provide the "i386" part you should be fine.
In your example all components provide the "i386" part, so all
of them can be installed.

With the aliases, this kind of detection is also possible, but
only after mapping the aliases back to the combination of included
architecture names.

In a few years, we'll probably only see "x86_64" binaries for
Mac OS, but until then, package installers will have to
be able to work out the problem of finding installable
distribution files among the available ones.

BTW: With Python 2.6, if you build using the x86_64 version of
Python, distutils will still use the "macosx-10.5-i386"
platform identifier. Should I file a bug for this ?

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Jan 14 2010)
>>> Python/Zope Consulting and Support ...        http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ...             http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...        http://python.egenix.com/
________________________________________________________________________

::: Try our new mxODBC.Connect Python Database Interface for free ! ::::


   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
    D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
           Registered at Amtsgericht Duesseldorf: HRB 46611
               http://www.egenix.com/company/contact/

From ronaldoussoren at mac.com  Thu Jan 14 16:43:46 2010
From: ronaldoussoren at mac.com (Ronald Oussoren)
Date: Thu, 14 Jan 2010 16:43:46 +0100
Subject: [Distutils] Platform naming standardization
In-Reply-To: <4B4EE5AE.20106@egenix.com>
References: <4B4CBA89.9020000@psu.edu> <4B4DE376.5030108@egenix.com>
	<115628741786360745376315588794785737544-Webmail@me.com>
	<4B4E05BE.3000703@egenix.com>
	<22F99734-448F-4CB7-90CF-974A8F27EBE4@mac.com>
	<4B4E4CC6.8070902@egenix.com>
	<A8E9DF44-D891-4A18-B910-DC204D55117C@mac.com>
	<4B4EE5AE.20106@egenix.com>
Message-ID: <E1CD413E-94B8-4A9D-A371-A0F4A6236763@mac.com>


On 14 Jan, 2010, at 10:36, M.-A. Lemburg wrote:

> Ronald Oussoren wrote:
>> 
>> On 13 Jan, 2010, at 23:44, M.-A. Lemburg wrote:
>> 
>>> Ronald Oussoren wrote:
>>>> 
>>>> On 13 Jan, 2010, at 18:41, M.-A. Lemburg wrote:
>>>> 
>>>>> Ronald Oussoren wrote:
>>>>>> 
>>>>>> On Wednesday, January 13, 2010, at 04:15PM, "M.-A. Lemburg" <mal at egenix.com> wrote:
>>>>>> 
>>>>>>> 
>>>>>>>> 2) On OS X, the modification to the value returned by
>>>>>>>> pkg_resources.get_platform() isn't correct for fat version of Python
>>>>>>>> 2.5, as detailed in setuptools issue 19.  To solve that, we're using the
>>>>>>>> patch I submitted to the issue (with a couple recent changes).
>>>>>>> 
>>>>>>> I think that using "fat" in the version string is wrong for
>>>>>>> Mac OS X, since there are many ways to build fat binaries.
>>>>>>> 
>>>>>>> Instead, the version string should include the details of
>>>>>>> all included builds, ie. 'x86', 'x64', 'ppc', 'ppc64'.
>>>>>> 
>>>>>> Maybe in the long run, but for now "fat" has a well-defined meaning for distutils: fat == ppc + x86_64. There is also a number of other variants, as described in the documentation for distutils.
>>>>> 
>>>>> I think you meant: fat == ppc + i386.
>>>> 
>>>> Thats right.
>>>>> 
>>>>> However, it's also possible to build binaries with ppc, i386 and
>>>>> x86_64 - as are shipped with Mac OS X 10.6, so "fat" is not really
>>>>> well-defined and could lead to trying to install 32-bit software for
>>>>> a 64-bit build of Python.
>>>> 
>>>> "fat" is well-defined for distutils, see the definition of get_platform at <http://docs.python.org/distutils/apiref.html>. 
>>>> 
>>>> For distutils "fat" is always a universal binary with architectures i386 and ppc, with alternate names for other variants.
>>> 
>>> Thanks for pointing that out, however, I don't think that creating
>>> aliases for combinations of various different architectures
>>> is a good idea.
>>> 
>>> It's better to make the included architectures explicit and use
>>> this logic for all platforms, not just Mac OS X.
>> 
>> I would probably have done that, knowing what I know now.   
>> 
>> Hashing out the details on what combinations of architectures are valid during installation will be fun though ;-). That is, if my python says its machine is "i386,x86_64" is it then acceptable to install an "i386" binary, an "i386,x86_64" binary, and "i386,ppc, x86_64" binary?
> 
> The point is that even though your Python binary may say it's
> "i386,x86_64", the version you run your application with
> will either be "i386" or "x86_64" (depending on the OS environment
> settings).
> 
> Now let's say you're running the "i386" version. As long as all
> installed components provide the "i386" part you should be fine.
> In your example all components provide the "i386" part, so all
> of them can be installed.

I don't agree, "easy_install somepackage" should install a component that supports at least all architectures supported by the Python binary.   Otherwise you might install a package and have problems later when you try to use it. 

An example of this is a recent 64-bit capable machine with older versions of Tkinter or wxPython:  on those systems python will run as a 64-bit binary by default, but you sometimes have to run python in 32-bit mode to be able to use Tkinter. It would be very annoying and possibly confusing when I install a library and end up not being able to use it sometimes.

I also regularly build standalone app bundles on one machine and run them on other machines, those should also included all components in all supported architectures. 

> 
> With the aliases, this kind of detection is also possible, but
> only after mapping the aliases back to the combination of included
> architecture names.
> 
> In a few years, we'll probably only see "x86_64" binaries for
> Mac OS, but until then, package installers will have to
> be able to work out the problem of finding installable
> distribution files among the available ones.

I agree, at least until the next new thing comes along (such as something arm-based).

> 
> BTW: With Python 2.6, if you build using the x86_64 version of
> Python, distutils will still use the "macosx-10.5-i386"
> platform identifier. Should I file a bug for this ?

That should be fixed in the repository, distutils assumed that the "uname -m" reflects the correct architecture and that is not true for a single-architecture build with default compiler flags on OSX 10.6.   

Ronald

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3567 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20100114/16f70599/attachment.bin>

From KairamR at coned.com  Thu Jan 14 22:53:12 2010
From: KairamR at coned.com (Kairam, Raj)
Date: Thu, 14 Jan 2010 16:53:12 -0500
Subject: [Distutils] Python DB-API and MySQLdb driver
Message-ID: <0A69F3794ED5F842B1A75AEF1D59EC43029F43AA@exchmbir.conedison.net>

Dear Sir,
 
I am looking to download the software that lets me connect to MySQL
3.23.52  in Python 2.6.4.8 running on HP-UX 11.00
 
Could you please help me with information on where I can obtain it?
 
A reply will be very much appreciated.
 
Thanks
Raj Kairam
kairamr at coned.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20100114/5550e222/attachment.htm>

From regebro at gmail.com  Fri Jan 15 09:47:17 2010
From: regebro at gmail.com (Lennart Regebro)
Date: Fri, 15 Jan 2010 09:47:17 +0100
Subject: [Distutils] Python DB-API and MySQLdb driver
In-Reply-To: <0A69F3794ED5F842B1A75AEF1D59EC43029F43AA@exchmbir.conedison.net>
References: <0A69F3794ED5F842B1A75AEF1D59EC43029F43AA@exchmbir.conedison.net>
Message-ID: <319e029f1001150047hc629e37o6099ec48b8212a01@mail.gmail.com>

On Thu, Jan 14, 2010 at 22:53, Kairam, Raj <KairamR at coned.com> wrote:
> Dear Sir,
>
> I am looking to download the software that lets me connect to MySQL 3.23.52
> ?in Python 2.6.4.8 running on HP-UX 11.00
>
> Could you please help me with information on where I can obtain it?

http://pypi.python.org/pypi has most third-party modules, including
mysql connections.

-- 
Lennart Regebro: http://regebro.wordpress.com/
Python 3 Porting: http://python-incompatibility.googlecode.com/
+33 661 58 14 64

From techtonik at gmail.com  Fri Jan 15 10:14:43 2010
From: techtonik at gmail.com (anatoly techtonik)
Date: Fri, 15 Jan 2010 11:14:43 +0200
Subject: [Distutils] pkg_resources get Distribution by module name
In-Reply-To: <94bdd2611001040618r5db924a7hd9e1bdf74a216c39@mail.gmail.com>
References: <d34314101001030414r1683b9e7p524f6cee0a15160c@mail.gmail.com>
	<94bdd2611001031228h42e09527r8c881aa0b2e7599e@mail.gmail.com>
	<d34314101001040603y45750b53t36ad3dbaa3d4c339@mail.gmail.com>
	<94bdd2611001040618r5db924a7hd9e1bdf74a216c39@mail.gmail.com>
Message-ID: <d34314101001150114w2dc7bc72o949afea66cfb8296@mail.gmail.com>

On Mon, Jan 4, 2010 at 4:18 PM, Tarek Ziad? <ziade.tarek at gmail.com> wrote:
>>>>
>>>> If there any way to get Distribution information given the module name
>>>> like 'trac.admin.web_ui' ?in setuptools?
>>>>
>>>> There is a problem to extract information about exact distribution
>>>> name and version when module is already imported in application (Trac
>>>> plugins).
>>>
>>> I am not sure exactly what you are trying to do, but :
>>>
>>> If your trac plugin was done using entry points (as it says at
>>> http://trac.edgewall.org/wiki/TracDev/PluginDevelopment), this means
>>> that you can
>>> use the iter_entry_points API from pkg_resources: You will get a
>>> EntryPoint object that contains a dist attribute, pointing to the
>>> distribution infos.
>>
>> Thanks. Already followed this way. Entrypoints is only one way to
>> discover plugins - they will work also if imported directly (there is
>> "plugins" folder in every user site setup). When plugin is imported,
>> everything we have is a name of its class, its module name and path to
>> module file.
>>
>> I need to figure out if given module belongs to any setuptools
>> Distribution to know if it possible to extract any useful information
>> from it to display to user in administration panel.
>
> As long as that "plugins" folder is loaded in your WorkingEnv, you
> could try to see if the module's __file__ path is under the location
> of one distribution listed in the working env.

How can I get the list of distributions for working env?

There is another approach that seems more reliable than entrypoints
and will be used in Trac 0.12 - scanning SOURCES.txt for available
distributions and checking if a given normalized module.__file__ is
present among these choices. If there is no distribution, we still
need a way to detect root package the module is imported from, the
path to the directory of this package and import directory for it.

Scanning SOURCES.txt can be an expensive operation without cache though.

> I can't think of another way. PEP 376 will make this task really
> simple in the future, as you will be able to directly ask for the list
> of distributions that have installed a given file.

List of distributions? Each imported file belongs to one distribution
only. If normalized path belongs to two simultaneously installed
distributions then I doubt I need this "new" system. =)

Considering PEP 376 I apologize for not being able to read it
completely, but as with many PEPs there is one major drawback - no use
cases. For me it should answer four questions:
1. What tasks can not be done currently?
2. What operations are too complicated?
3. What are proposed solutions?
4. What problems should be solved before, during and after PEP implementation?
In the context of my problem I can not see how PEP 376 help with
Python packages installed into PYTHONPATH, .eggs that present in
PYTHONPATH and modules without distribution information. How can it
help to figure out the root package or distribution the imported
module belongs to. Are there any other PEPs for this?

BTW, there is "fils" typo in PEP 376.

-- 
anatoly t.

From ziade.tarek at gmail.com  Fri Jan 15 10:29:44 2010
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Fri, 15 Jan 2010 10:29:44 +0100
Subject: [Distutils] pkg_resources get Distribution by module name
In-Reply-To: <d34314101001150114w2dc7bc72o949afea66cfb8296@mail.gmail.com>
References: <d34314101001030414r1683b9e7p524f6cee0a15160c@mail.gmail.com>
	<94bdd2611001031228h42e09527r8c881aa0b2e7599e@mail.gmail.com>
	<d34314101001040603y45750b53t36ad3dbaa3d4c339@mail.gmail.com>
	<94bdd2611001040618r5db924a7hd9e1bdf74a216c39@mail.gmail.com>
	<d34314101001150114w2dc7bc72o949afea66cfb8296@mail.gmail.com>
Message-ID: <94bdd2611001150129iad94edax8ce88054a4494a59@mail.gmail.com>

On Fri, Jan 15, 2010 at 10:14 AM, anatoly techtonik <techtonik at gmail.com> wrote:
[..]
>> As long as that "plugins" folder is loaded in your WorkingEnv, you
>> could try to see if the module's __file__ path is under the location
>> of one distribution listed in the working env.
>
> How can I get the list of distributions for working env?

See Setuptools or Distribute doc, and in particular pkg_resources

>
> List of distributions? Each imported file belongs to one distribution
> only. If normalized path belongs to two simultaneously installed
> distributions then I doubt I need this "new" system. =)

Not necessarely. While this is not happening often, a module or package can
be installed by two distributions. (or "package distribution", or
"parcels" ;) ).

> Considering PEP 376 I apologize for not being able to read it
> completely, but as with many PEPs there is one major drawback - no use
> cases.

MMmm. I thought these two use cases where obvious:

- uninstall distributions
- query installed distributions (like what setuptools provides)

Of course patches are welcome to make it more understandable.

> In the context of my problem I can not see how PEP 376 help with
> Python packages installed into PYTHONPATH, .eggs that present in
> PYTHONPATH and modules without distribution information. How can it
> help to figure out the root package or distribution the imported
> module belongs to. Are there any other PEPs for this?

The code that will be developed for this PEP, as Setutpools is doing,
will make it work against sys.path, and let you browse all
installed/reachable distributions and their files. Meaning that you
will be able to rebuild the info you need. (and make it work on
arbitrary locations if required)

the RECORD file in PEP 376 replaces SOURCES.txt, so you will be able
to use a similar approach than Trac but through APIs

>
> BTW, there is "fils" typo in PEP 376.

Thanks.

> --
> anatoly t.
>



-- 
Tarek Ziad? | http://ziade.org

From olaf at conradi.org  Sun Jan 17 17:16:05 2010
From: olaf at conradi.org (Olaf Conradi)
Date: Sun, 17 Jan 2010 17:16:05 +0100
Subject: [Distutils] buildout config question
In-Reply-To: <1099b90b1001130444w2ab8d1f8u8f63ca9f6d2f548d@mail.gmail.com>
References: <118246c11001091501r2ac46367je763ce08ec6f9d1b@mail.gmail.com>
	<4B4D81E7.10005@simplistix.co.uk>
	<1099b90b1001130444w2ab8d1f8u8f63ca9f6d2f548d@mail.gmail.com>
Message-ID: <118246c11001170816k67a736d2y2109ed73b12faf77@mail.gmail.com>

Hi,

2010/1/13 Jim Fulton <jim at zope.com>:
> On Wed, Jan 13, 2010 at 3:18 AM, Chris Withers <chris at simplistix.co.uk> wrote:
>
> Thanks for responding.
>
>> Olaf Conradi wrote:
>>>
>>> [bank2ledger]
>>> recipe = zc.recipe.egg:scripts
>>> eggs =
>>> ? ?bank2ledger
>>> ? ?pyxdg
>>>
>>> [pylint]
>>> recipe = zc.recipe.egg
>>> eggs =
>>> ? ?pylint
>>> ? ?${bank2ledger:eggs}
>>> entry-points = pylint=pylint.lint:Run
>>> arguments = sys.argv[1:]+[
>>> ? ?'--output-format=parseable',
>>> ? ?'bank2ledger']
>>
>> Both of these sections generate a bin/bank2ledger script.
>
> Yup.

So listing entries under eggs not only adds those eggs to the python
path, it also installs any associated scripts. That wasn't clear to me
when I read the zc.recipe.egg documentation the first time.

>> This is an error, and one that buildout should likely complain about.
>
> I don't consider it an error. I often override a script generated by another
> part.
>
> I can see benefit in buildout saying something about this situation.
>
>> You need to arrange for one of them to have a different name.
>> zc.recipe.egg may have a way to support that, check the docs and let us know
>> what you find.
>
> Yup. ?http://pypi.python.org/pypi/zc.recipe.egg#controlling-script-generation

Ah, when I add scripts = pylint to the second part it only generates
that script.

Thanks, I have it working now :)

Cheers,
 -Olaf

From irene.formaioni at intecs.it  Tue Jan 12 12:32:32 2010
From: irene.formaioni at intecs.it (Irene Formaioni)
Date: Tue, 12 Jan 2010 12:32:32 +0100
Subject: [Distutils] error in using easy_install command
Message-ID: <4B4C5DD0.1020308@intecs.it>

Hi,
i've installed setuptools and i try to use easy_install but it doesn't 
work. ( i use Windows XP)
 From the IDLE (GUI)  i obtain this error:

IDLE 2.6.3     
 >>> easy_install -f http://pypi.python.org/pypi/functest/0.8.8 functest
SyntaxError: invalid syntax
 >>>

You can tell me why, where i mistake .

Thank you
-- 

 

*Irene Formaioni
*

*Intecs - Informatica e Tecnologia del Software
*via E. Giannessi,5
Loc. Ospedaletto I-56121 Pisa

E-Mail: irene.formaioni at intecs.it
<mailto:irene.formaioni at intecs.it>Telefono (diretto): +39 050 96 57 557
Centralino: +39 050 96 57 411
Fax: +39 050 96 57 400

www.intecs.it <http://www.intecs.it>



LEGAL DISCLAIMER:
The contents of this email and any transmitted files are confidential and intended solely for the use of the individual or entity to whom they are addressed. We hereby exclude any warranty and any liability as to the quality or accuracy of the contents of this email and any attached transmitted files. If you are not the intended recipient, be advised that you have received this email in error and that any use, dissemination, forwarding, printing or copying of this email is strictly prohibited. If you have received this email in error please contact the sender and delete the material from any computer.

From wirawan0 at gmail.com  Tue Jan 12 20:46:08 2010
From: wirawan0 at gmail.com (Wirawan Purwanto)
Date: Tue, 12 Jan 2010 14:46:08 -0500
Subject: [Distutils] Problem with library search in distutils
Message-ID: <44bfab7e1001121146v1fab240axf85d1682c3e9700e@mail.gmail.com>

Hi,

I would like to report an issue with python's distutils. I ran into
trouble with my numpy installation, which seems to be caused by
distutils. What I am to do is to link my numpy shared objects against
Intel MKL (version 10.1)

I have the following in my site.cfg:

[mkl]
library_dirs = /share/apps/intel/mkl/lib/em64t:/share/apps/intel/lib/intel64
mkl_libs = mkl_gf_lp64, mkl_intel_thread, mkl_core, iomp5

This is to follow the link instruction in MKL 10 manual. The catch is,
the two library dirs contain part of the library files to be linked
in, that is:

/share/apps/intel/mkl/lib/em64t contains: mkl_gf_lp64,
mkl_intel_thread, mkl_core
/share/apps/intel/lib/intel64 contains: iomp5

It seems that this situation is not handled well by distutils. When I
traced the python build script (by adding printout to
distutils/system_info.py), I found out that search algorithm in
distutils.system_info class (method: check_libs2, which in turn calls
_check_libs, which in turn calls _lib_list) requires that all five
libraries above are sought to be together in one of the subdirs given
above (either /share/apps/intel/mkl/lib/em64t  or
/share/apps/intel/lib/intel64). The method cannot handle libraries
that are scattered as my situation described above.

Note that I could have fooled the build system by providing softlink
to all these files in a single subdir, but it seems that system_info
could be fixed to handle situations above without much muddling like
this.

The problem was first detected with numpy version 1.2.1 (which is old,
I know), but a quick inspection of the system_info module included
there shows that not much has changed since then compared to the most
recent distutils (included with my python 2.6.4 installation).

-- 
Wirawan Purwanto
College of William and Mary
Physics Department
Williamsburg, VA 23187

From ziade.tarek at gmail.com  Sun Jan 17 23:32:29 2010
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Sun, 17 Jan 2010 23:32:29 +0100
Subject: [Distutils] error in using easy_install command
In-Reply-To: <4B4C5DD0.1020308@intecs.it>
References: <4B4C5DD0.1020308@intecs.it>
Message-ID: <94bdd2611001171432hb607538k4861bcf0e071b357@mail.gmail.com>

On Tue, Jan 12, 2010 at 12:32 PM, Irene Formaioni
<irene.formaioni at intecs.it> wrote:
> Hi,
> i've installed setuptools and i try to use easy_install but it doesn't work.
> ( i use Windows XP)
> From the IDLE (GUI) ?i obtain this error:
>
> IDLE 2.6.3 ? ? >>> easy_install -f
> http://pypi.python.org/pypi/functest/0.8.8 functest
> SyntaxError: invalid syntax
>>>>
>
> You can tell me why, where i mistake .
>

Hi. easy_install is a command, not to be used in the prompt but in the
command-line shell.

try to launch this (check this path I am not sure, I am nt under win32
so I am doing this by memory):

"c:\Python26\Scripts\easy_install.exe"

you can also add "c:\Python26\Scripts" in your PATH environment
variable so you can run "easy_install.exe" directly

> Thank you
> --
>
>
>
> *Irene Formaioni
> *
>
> *Intecs - Informatica e Tecnologia del Software
> *via E. Giannessi,5
> Loc. Ospedaletto I-56121 Pisa
>
> E-Mail: irene.formaioni at intecs.it
> <mailto:irene.formaioni at intecs.it>Telefono (diretto): +39 050 96 57 557
> Centralino: +39 050 96 57 411
> Fax: +39 050 96 57 400
>
> www.intecs.it <http://www.intecs.it>
>
>
>
> LEGAL DISCLAIMER:
> The contents of this email and any transmitted files are confidential and
> intended solely for the use of the individual or entity to whom they are
> addressed. We hereby exclude any warranty and any liability as to the
> quality or accuracy of the contents of this email and any attached
> transmitted files. If you are not the intended recipient, be advised that
> you have received this email in error and that any use, dissemination,
> forwarding, printing or copying of this email is strictly prohibited. If you
> have received this email in error please contact the sender and delete the
> material from any computer.
> _______________________________________________
> Distutils-SIG maillist ?- ?Distutils-SIG at python.org
> http://mail.python.org/mailman/listinfo/distutils-sig
>



-- 
Tarek Ziad? | http://ziade.org

From david.lyon at preisshare.net  Mon Jan 18 00:54:29 2010
From: david.lyon at preisshare.net (David Lyon)
Date: Sun, 17 Jan 2010 18:54:29 -0500
Subject: [Distutils] Platform naming standardization
In-Reply-To: <4B4EE5AE.20106@egenix.com>
References: <4B4CBA89.9020000@psu.edu>
	<4B4DE376.5030108@egenix.com>	<115628741786360745376315588794785737544-Webmail@me.com>	<4B4E05BE.3000703@egenix.com>	<22F99734-448F-4CB7-90CF-974A8F27EBE4@mac.com>	<4B4E4CC6.8070902@egenix.com>
	<A8E9DF44-D891-4A18-B910-DC204D55117C@mac.com>
	<4B4EE5AE.20106@egenix.com>
Message-ID: <e05aadb2f7ec040dbac1ff28305c2f58@preisshare.net>

On Thu, 14 Jan 2010 10:36:46 +0100, "M.-A. Lemburg" <mal at egenix.com> wrote:

>>>>>>> Instead, the version string should include the details of
>>>>>>> all included builds, ie. 'x86', 'x64', 'ppc', 'ppc64'.

>> Hashing out the details on what combinations of architectures are valid
>> during installation will be fun though ;-). That is, if my python says
>> its machine is "i386,x86_64" is it then acceptable to install an "i386"
>> binary, an "i386,x86_64" binary, and "i386,ppc, x86_64" binary?
> 
> The point is that even though your Python binary may say it's
> "i386,x86_64", the version you run your application with
> will either be "i386" or "x86_64" (depending on the OS environment
> settings).

That's right.

> Now let's say you're running the "i386" version. As long as all
> installed components provide the "i386" part you should be fine.
> In your example all components provide the "i386" part, so all
> of them can be installed.

The main point here though is being able to trigger the correct
build for non-standard configuration, no matter what the
platform. We're having the same issue on Windows as it
is running the same processors.

> In a few years, we'll probably only see "x86_64" binaries for
> Mac OS, but until then, package installers will have to
> be able to work out the problem of finding installable
> distribution files among the available ones.

We'll see what if anything gets changed/fixed.

I'm concerned about the excessive use of code-freeze-spray
being used in 2010. That's where you take 5-10 year old
code and just freeze it into place.

I'd really like to see distutils create packages and run
in a browser window. That's my wish to santa. 

Having a 64-bit processor and a 10 year old command line
interface on distutils, seems somewhat wrong in this
millenia.

There really is so much to do.. we could make a really
fresh start with Python 3 and make it really different
and better than Python 2.x

I'd love to see a plan or a roadmap for packaging for 2010..

David



From cournape at gmail.com  Mon Jan 18 02:41:18 2010
From: cournape at gmail.com (David Cournapeau)
Date: Mon, 18 Jan 2010 10:41:18 +0900
Subject: [Distutils] Problem with library search in distutils
In-Reply-To: <44bfab7e1001121146v1fab240axf85d1682c3e9700e@mail.gmail.com>
References: <44bfab7e1001121146v1fab240axf85d1682c3e9700e@mail.gmail.com>
Message-ID: <5b8d13221001171741u372a069cy708a053c627c3c14@mail.gmail.com>

On Wed, Jan 13, 2010 at 4:46 AM, Wirawan Purwanto <wirawan0 at gmail.com> wrote:
> Hi,
>
> I would like to report an issue with python's distutils. I ran into
> trouble with my numpy installation, which seems to be caused by
> distutils. What I am to do is to link my numpy shared objects against
> Intel MKL (version 10.1)

Please report numpy build issues on numpy ML - everybody would will be
able to help you will be on numpy ML, whereas not that many people
able to help you hang out here.
>
> Note that I could have fooled the build system by providing softlink
> to all these files in a single subdir, but it seems that system_info
> could be fixed to handle situations above without much muddling like
> this.

yes, the whole distutils scheme (numpy.distutils to be precise) scheme
to detect libraries is not very robust to say the least.

You should use numscons if you want to link with the MKL, it is much easier.

David

From nate at psu.edu  Mon Jan 18 13:43:53 2010
From: nate at psu.edu (Nate Coraor)
Date: Mon, 18 Jan 2010 07:43:53 -0500
Subject: [Distutils] Platform naming standardization
In-Reply-To: <e05aadb2f7ec040dbac1ff28305c2f58@preisshare.net>
References: <4B4CBA89.9020000@psu.edu>	<4B4DE376.5030108@egenix.com>	<115628741786360745376315588794785737544-Webmail@me.com>	<4B4E05BE.3000703@egenix.com>	<22F99734-448F-4CB7-90CF-974A8F27EBE4@mac.com>	<4B4E4CC6.8070902@egenix.com>	<A8E9DF44-D891-4A18-B910-DC204D55117C@mac.com>	<4B4EE5AE.20106@egenix.com>
	<e05aadb2f7ec040dbac1ff28305c2f58@preisshare.net>
Message-ID: <4B545789.9060603@psu.edu>

David Lyon wrote:
> On Thu, 14 Jan 2010 10:36:46 +0100, "M.-A. Lemburg" <mal at egenix.com> wrote:
> 
>>>>>>>> Instead, the version string should include the details of
>>>>>>>> all included builds, ie. 'x86', 'x64', 'ppc', 'ppc64'.
> 
>>> Hashing out the details on what combinations of architectures are valid
>>> during installation will be fun though ;-). That is, if my python says
>>> its machine is "i386,x86_64" is it then acceptable to install an "i386"
>>> binary, an "i386,x86_64" binary, and "i386,ppc, x86_64" binary?
>> The point is that even though your Python binary may say it's
>> "i386,x86_64", the version you run your application with
>> will either be "i386" or "x86_64" (depending on the OS environment
>> settings).
> 
> That's right.
> 
>> Now let's say you're running the "i386" version. As long as all
>> installed components provide the "i386" part you should be fine.
>> In your example all components provide the "i386" part, so all
>> of them can be installed.
> 
> The main point here though is being able to trigger the correct
> build for non-standard configuration, no matter what the
> platform. We're having the same issue on Windows as it
> is running the same processors.
> 
>> In a few years, we'll probably only see "x86_64" binaries for
>> Mac OS, but until then, package installers will have to
>> be able to work out the problem of finding installable
>> distribution files among the available ones.
> 
> We'll see what if anything gets changed/fixed.
> 
> I'm concerned about the excessive use of code-freeze-spray
> being used in 2010. That's where you take 5-10 year old
> code and just freeze it into place.
> 
> I'd really like to see distutils create packages and run
> in a browser window. That's my wish to santa. 
> 
> Having a 64-bit processor and a 10 year old command line
> interface on distutils, seems somewhat wrong in this
> millenia.
> 
> There really is so much to do.. we could make a really
> fresh start with Python 3 and make it really different
> and better than Python 2.x
> 
> I'd love to see a plan or a roadmap for packaging for 2010..

I'd hate to see this only end up in 3.  We'll probably be supporting 2.x 
for a long time.

Are we any closer to a plan? =)  I just found another: (g)libc version.

--nate

> David
> 
> 
> _______________________________________________
> Distutils-SIG maillist  -  Distutils-SIG at python.org
> http://mail.python.org/mailman/listinfo/distutils-sig

From doug.hellmann at gmail.com  Mon Jan 18 14:44:51 2010
From: doug.hellmann at gmail.com (Doug Hellmann)
Date: Mon, 18 Jan 2010 08:44:51 -0500
Subject: [Distutils] Distribute bootstrap question
Message-ID: <FD8F2F9E-409E-4C85-A45C-8F4B601639DA@gmail.com>

I just released my first new piece of software using Distribute, and  
I'm still confused about whether I have the packaging correct.  I  
think not, because a user has reported receiving a SandboxViolation  
error when trying to install the package with easy_install (bug report  
at: http://bitbucket.org/dhellmann/ical2org/issue/1/unable-to-install-ical2org-with) 
.  The relevant portion of the error message seems to be:

Searching for distribute
Reading http://pypi.python.org/simple/distribute/
Reading http://packages.python.org/distribute
Best match: distribute 0.6.10
Downloading http://pypi.python.org/packages/source/d/distribute/distribute-0.6.10.tar.gz#md5 
=99fb4b3e4ef0861bba11aa1905e89fed
Processing distribute-0.6.10.tar.gz
Running distribute-0.6.10/setup.py -q bdist_egg --dist-dir /tmp/ 
easy_install-aO9HwB/distribute-0.6.10/egg-dist-tmp-woULY8
Before install bootstrap.
Scanning installed packages
Setuptools installation detected at /System/Library/Frameworks/ 
Python.framework/Versions/2.5/Extras/lib/python
Non-egg installation
Removing elements out of the way...
Renaming /System/Library/Frameworks/Python.framework/Versions/2.5/ 
Extras/lib/python/setuptools-0.6c7-py2.5.egg-info into /System/Library/ 
Frameworks/Python.framework/Versions/2.5/Extras/lib/python/ 
setuptools-0.6c7-py2.5.egg-info.OLD.1263800301.89
error: SandboxViolation: mkdir('/System/Library/Frameworks/ 
Python.framework/Versions/2.5/Extras/lib/python/setuptools-0.6c7- 
py2.5.egg-info',) {}

That looks like the script is trying to install Distribute itself,  
based I suppose on having it in the install_requires list in my  
setup.py.  I added distribute to install_requires after on an apparent  
misreading of the instructions on http://pypi.python.org/pypi/ 
distribute.

So, my questions:

1. While researching the problem this morning, I came across the  
instructions at http://packages.python.org/distribute/setuptools.html#using-setuptools-without-bundling-it 
, which seem like a much more sensible way to bootstrap the  
installation of Distribute than install_requires.  Should I have used  
that instead of install_requires?

2. If I don't require Distribute for installation, will my package  
work with the older setuptools (assuming I'm not using any Distribute- 
specific features, which I don't think I am, but I'm not sure I know  
what those are).  In a nutshell, do I need to force my user to install  
Distribute at all before using my package?  And if so, what is the  
preferred way of doing that?

Thanks,
Doug


From david.lyon at preisshare.net  Mon Jan 18 15:25:52 2010
From: david.lyon at preisshare.net (David Lyon)
Date: Tue, 19 Jan 2010 01:25:52 +1100 (EST)
Subject: [Distutils] Platform naming standardization
In-Reply-To: <4B545789.9060603@psu.edu>
References: <4B4CBA89.9020000@psu.edu> <4B4DE376.5030108@egenix.com>
	<115628741786360745376315588794785737544-Webmail@me.com>
	<4B4E05BE.3000703@egenix.com>
	<22F99734-448F-4CB7-90CF-974A8F27EBE4@mac.com>
	<4B4E4CC6.8070902@egenix.com>
	<A8E9DF44-D891-4A18-B910-DC204D55117C@mac.com>
	<4B4EE5AE.20106@egenix.com>
	<e05aadb2f7ec040dbac1ff28305c2f58@preisshare.net>
	<4B545789.9060603@psu.edu>
Message-ID: <56612.115.128.16.38.1263824752.squirrel@syd-srv02.ezyreg.com>

> Nate wrote:

> I'd hate to see this only end up in 3.  We'll probably be supporting 2.x
> for a long time.
>
> Are we any closer to a plan? =)  I just found another: (g)libc version.

Well everyday we get closer to seeing the roadmap..

I can give an official answer on that. See:

http://us.pycon.org/2010/conference/talks/?search=packaging#63.%20%20The%20state%20of%20Packaging

Here my friend Tarek will speak on the distutils revamp that I have been
suggesting. If you can get along, it will be an extremely interesting
session..

David



From mal at egenix.com  Mon Jan 18 16:44:58 2010
From: mal at egenix.com (M.-A. Lemburg)
Date: Mon, 18 Jan 2010 16:44:58 +0100
Subject: [Distutils] Platform naming standardization
In-Reply-To: <E1CD413E-94B8-4A9D-A371-A0F4A6236763@mac.com>
References: <4B4CBA89.9020000@psu.edu>
	<4B4DE376.5030108@egenix.com>	<115628741786360745376315588794785737544-Webmail@me.com>	<4B4E05BE.3000703@egenix.com>	<22F99734-448F-4CB7-90CF-974A8F27EBE4@mac.com>	<4B4E4CC6.8070902@egenix.com>	<A8E9DF44-D891-4A18-B910-DC204D55117C@mac.com>	<4B4EE5AE.20106@egenix.com>
	<E1CD413E-94B8-4A9D-A371-A0F4A6236763@mac.com>
Message-ID: <4B5481FA.4070800@egenix.com>

Ronald Oussoren wrote:
> 
> ["fat" binaries on Mac OS X]
>
>>>> It's better to make the included architectures explicit and use
>>>> this logic for all platforms, not just Mac OS X.
>>>
>>> I would probably have done that, knowing what I know now.   
>>>
>>> Hashing out the details on what combinations of architectures are valid during installation will be fun though ;-). That is, if my python says its machine is "i386,x86_64" is it then acceptable to install an "i386" binary, an "i386,x86_64" binary, and "i386,ppc, x86_64" binary?
>>
>> The point is that even though your Python binary may say it's
>> "i386,x86_64", the version you run your application with
>> will either be "i386" or "x86_64" (depending on the OS environment
>> settings).
>>
>> Now let's say you're running the "i386" version. As long as all
>> installed components provide the "i386" part you should be fine.
>> In your example all components provide the "i386" part, so all
>> of them can be installed.
> 
> I don't agree, "easy_install somepackage" should install a component that supports at least all architectures supported by the Python binary.   Otherwise you might install a package and have problems later when you try to use it. 
> 
> An example of this is a recent 64-bit capable machine with older versions of Tkinter or wxPython:  on those systems python will run as a 64-bit binary by default, but you sometimes have to run python in 32-bit mode to be able to use Tkinter. It would be very annoying and possibly confusing when I install a library and end up not being able to use it sometimes.
> 
> I also regularly build standalone app bundles on one machine and run them on other machines, those should also included all components in all supported architectures. 

A package manager should of course try to install the best match
per default and best match should probably mean: use the binary
that supports all architecture parts supported by the currently
running Python binary.

However, it is well possible that some binary packages do not
come in all combinations supported by the Python binary, but do
come in the variant currently running. In such a case, the
user should still be able to install the binary package - perhaps
with a warning that the installed version won't run on some other
supported variants.

With the current aliasing of architecture combinations this
won't be possible, so the user won't be able to install an
ppc/i386 egg, even if she only ever uses the i386 part of a
ppc/i386/x64_86 Python binary.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Jan 18 2010)
>>> Python/Zope Consulting and Support ...        http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ...             http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...        http://python.egenix.com/
________________________________________________________________________

::: Try our new mxODBC.Connect Python Database Interface for free ! ::::


   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
    D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
           Registered at Amtsgericht Duesseldorf: HRB 46611
               http://www.egenix.com/company/contact/

From wirawan0 at gmail.com  Mon Jan 18 16:55:32 2010
From: wirawan0 at gmail.com (Wirawan Purwanto)
Date: Mon, 18 Jan 2010 10:55:32 -0500
Subject: [Distutils] Problem with library search in distutils
In-Reply-To: <5b8d13221001171741u372a069cy708a053c627c3c14@mail.gmail.com>
References: <44bfab7e1001121146v1fab240axf85d1682c3e9700e@mail.gmail.com>
	<5b8d13221001171741u372a069cy708a053c627c3c14@mail.gmail.com>
Message-ID: <44bfab7e1001180755r5f9e6c02r29b321cd2504633c@mail.gmail.com>

Thanks David for your reply. I see, I wasn't aware of a better effort
(numscons) below. Thanks for pointing that out.

Wirawan

On Sun, Jan 17, 2010 at 8:41 PM, David Cournapeau <cournape at gmail.com>wrote:

> On Wed, Jan 13, 2010 at 4:46 AM, Wirawan Purwanto <wirawan0 at gmail.com>
> wrote:
> > Hi,
> >
> > I would like to report an issue with python's distutils. I ran into
> > trouble with my numpy installation, which seems to be caused by
> > distutils. What I am to do is to link my numpy shared objects against
> > Intel MKL (version 10.1)
>
> Please report numpy build issues on numpy ML - everybody would will be
> able to help you will be on numpy ML, whereas not that many people
> able to help you hang out here.
> >
> > Note that I could have fooled the build system by providing softlink
> > to all these files in a single subdir, but it seems that system_info
> > could be fixed to handle situations above without much muddling like
> > this.
>
> yes, the whole distutils scheme (numpy.distutils to be precise) scheme
> to detect libraries is not very robust to say the least.
>
> You should use numscons if you want to link with the MKL, it is much
> easier.
>
> David
>



-- 
Wirawan Purwanto
College of William and Mary
Physics Department
Williamsburg, VA 23187
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20100118/adedc859/attachment-0001.htm>

From chris at simplistix.co.uk  Tue Jan 19 11:15:42 2010
From: chris at simplistix.co.uk (Chris Withers)
Date: Tue, 19 Jan 2010 10:15:42 +0000
Subject: [Distutils] [buildout] branches languishing? (site-packages and
	distutils scripts)
Message-ID: <4B55864E.3080108@simplistix.co.uk>

Hi All,

I'm wondering what the state of play is with the following branches:

reinout-scripts
gary-4-include-site-packages

What more needs to happen for these to get merged to trunk and a release 
made?

cheers,

Chris


From jim at zope.com  Tue Jan 19 13:06:00 2010
From: jim at zope.com (Jim Fulton)
Date: Tue, 19 Jan 2010 07:06:00 -0500
Subject: [Distutils] [buildout] branches languishing? (site-packages and
	distutils scripts)
In-Reply-To: <4B55864E.3080108@simplistix.co.uk>
References: <4B55864E.3080108@simplistix.co.uk>
Message-ID: <1099b90b1001190406u52ba46fbs284e1a2a54489de2@mail.gmail.com>

On Tue, Jan 19, 2010 at 5:15 AM, Chris Withers <chris at simplistix.co.uk> wrote:
> Hi All,
>
> I'm wondering what the state of play is with the following branches:
>
> reinout-scripts

Not sure. I need to review this.

> gary-4-include-site-packages

afaik, Gary is reconsidering his approach.  I'm not sure what the
current status is.

Jim

-- 
Jim Fulton

From reinout at vanrees.org  Tue Jan 19 17:00:45 2010
From: reinout at vanrees.org (Reinout van Rees)
Date: Tue, 19 Jan 2010 17:00:45 +0100
Subject: [Distutils] [buildout] branches languishing? (site-packages and
 distutils scripts)
In-Reply-To: <1099b90b1001190406u52ba46fbs284e1a2a54489de2@mail.gmail.com>
References: <4B55864E.3080108@simplistix.co.uk>
	<1099b90b1001190406u52ba46fbs284e1a2a54489de2@mail.gmail.com>
Message-ID: <hj4kvc$11i$1@ger.gmane.org>

On 01/19/2010 01:06 PM, Jim Fulton wrote:
> On Tue, Jan 19, 2010 at 5:15 AM, Chris Withers<chris at simplistix.co.uk>  wrote:
>> Hi All,
>>
>> I'm wondering what the state of play is with the following branches:
>>
>> reinout-scripts
>
> Not sure. I need to review this.

Do you need me to make a fresh branch off the current trunk?

The changes were pretty isolated in one spot if memory serves me.

Only possibly tricky bit is the test I added for it: the only practical 
way I could find to test it was to add an old-style script to one of the 
existing demo test packages. iirc.



Reinout

-- 
Reinout van Rees - reinout at vanrees.org - http://reinout.vanrees.org
Programmer/advisor at http://www.nelen-schuurmans.nl
"Military engineers build missiles. Civil engineers build targets"


From reinout at vanrees.org  Tue Jan 19 17:08:23 2010
From: reinout at vanrees.org (Reinout van Rees)
Date: Tue, 19 Jan 2010 17:08:23 +0100
Subject: [Distutils] [buildout] branches languishing? (site-packages and
 distutils scripts)
In-Reply-To: <4B55864E.3080108@simplistix.co.uk>
References: <4B55864E.3080108@simplistix.co.uk>
Message-ID: <hj4ldn$4as$1@ger.gmane.org>

On 01/19/2010 11:15 AM, Chris Withers wrote:
>
> gary-4-include-site-packages

include-site-packages branch: from what I see in the changelog 
(http://tinyurl.com/y9x27oj), this would mean that a globally installed 
package is found by buildout/setuptools' dependency handling?

So if I install PIL with debian's apt-get, buildout doesn't attempt to 
grab another copy from pypi?  Unsure about that from reading the changelog.


Reinout


-- 
Reinout van Rees - reinout at vanrees.org - http://reinout.vanrees.org
Programmer/advisor at http://www.nelen-schuurmans.nl
"Military engineers build missiles. Civil engineers build targets"


From jim at zope.com  Tue Jan 19 17:16:21 2010
From: jim at zope.com (Jim Fulton)
Date: Tue, 19 Jan 2010 11:16:21 -0500
Subject: [Distutils] [buildout] branches languishing? (site-packages and
	distutils scripts)
In-Reply-To: <hj4kvc$11i$1@ger.gmane.org>
References: <4B55864E.3080108@simplistix.co.uk>
	<1099b90b1001190406u52ba46fbs284e1a2a54489de2@mail.gmail.com>
	<hj4kvc$11i$1@ger.gmane.org>
Message-ID: <1099b90b1001190816l6af94f67h9074435418034951@mail.gmail.com>

On Tue, Jan 19, 2010 at 11:00 AM, Reinout van Rees <reinout at vanrees.org> wrote:
> On 01/19/2010 01:06 PM, Jim Fulton wrote:
>>
>> On Tue, Jan 19, 2010 at 5:15 AM, Chris Withers<chris at simplistix.co.uk>
>> ?wrote:
>>>
>>> Hi All,
>>>
>>> I'm wondering what the state of play is with the following branches:
>>>
>>> reinout-scripts
>>
>> Not sure. I need to review this.
>
> Do you need me to make a fresh branch off the current trunk?

No

Jim

-- 
Jim Fulton

From gary.poster at canonical.com  Tue Jan 19 17:29:42 2010
From: gary.poster at canonical.com (Gary Poster)
Date: Tue, 19 Jan 2010 11:29:42 -0500
Subject: [Distutils] [buildout] branches languishing? (site-packages and
	distutils scripts)
In-Reply-To: <hj4ldn$4as$1@ger.gmane.org>
References: <4B55864E.3080108@simplistix.co.uk> <hj4ldn$4as$1@ger.gmane.org>
Message-ID: <D18914EE-6430-48D8-A59F-CD2DD5A5AFD1@canonical.com>


On Jan 19, 2010, at 11:08 AM, Reinout van Rees wrote:

> On 01/19/2010 11:15 AM, Chris Withers wrote:
>> 
>> gary-4-include-site-packages

I'm getting back to this this week.  The new branch is svn+ssh://svn.zope.org/repos/main/zc.buildout/branches/gary-4 .  It has most of what I intend but needs a bit more work.  It could be ready for Jim's review this week.

> include-site-packages branch: from what I see in the changelog (http://tinyurl.com/y9x27oj), this would mean that a globally installed package is found by buildout/setuptools' dependency handling?
> 
> So if I install PIL with debian's apt-get, buildout doesn't attempt to grab another copy from pypi?  Unsure about that from reading the changelog.

The old branch supported that, with the right buildout configuration, and if apt-get installed the package as an egg.

The new branch does not try for that.  It simply builds dependency sets ignoring the Python's site.py (so, ignoring site-packages).  If desired, you can have scripts import site.py *after* the buildout eggs have been set up (so if your buildout did not require PIL, but your system's Python had it, your code could use the system's version if you were willing to open yourself up to that potential fragility), but that's the only integration.

If it is really desired, I could look at porting the work later from the previous branch (after the basic work on the new approach lands).  I am currently of the opinion that it is too tricky for too rare of a win (and I don't need it right now ;-) ).

Gary

From yonsy at aureal.com.pe  Tue Jan 19 18:08:33 2010
From: yonsy at aureal.com.pe (Yonsy Solis)
Date: Tue, 19 Jan 2010 12:08:33 -0500
Subject: [Distutils] [buildout] branches languishing? (site-packages and
 distutils scripts)
In-Reply-To: <D18914EE-6430-48D8-A59F-CD2DD5A5AFD1@canonical.com>
References: <4B55864E.3080108@simplistix.co.uk> <hj4ldn$4as$1@ger.gmane.org>
	<D18914EE-6430-48D8-A59F-CD2DD5A5AFD1@canonical.com>
Message-ID: <1263920913.495.9.camel@alisah>

On Tue, 2010-01-19 at 11:29 -0500, Gary Poster wrote:

> The new branch does not try for that.  It simply builds dependency sets ignoring the Python's site.py (so, ignoring site-packages).  If desired, you can have scripts import site.py *after* the buildout eggs have been set up (so if your buildout did not require PIL, but your system's Python had it, your code could use the system's version if you were willing to open yourself up to that potential fragility), but that's the only integration.
> 
> If it is really desired, I could look at porting the work later from the previous branch (after the basic work on the new approach lands).  I am currently of the opinion that it is too tricky for too rare of a win (and I don't need it right now ;-) ).

Gary, exist any way that this feature to exclude the site-packages can
be coded like an buildout extension ?

-- 
Yonsy Solis
Aureal Systems
(mov) 989-124-141
(www) http://www.aureal.com.pe



From gary.poster at canonical.com  Tue Jan 19 20:26:37 2010
From: gary.poster at canonical.com (Gary Poster)
Date: Tue, 19 Jan 2010 14:26:37 -0500
Subject: [Distutils] [buildout] branches languishing? (site-packages and
	distutils scripts)
In-Reply-To: <1263920913.495.9.camel@alisah>
References: <4B55864E.3080108@simplistix.co.uk> <hj4ldn$4as$1@ger.gmane.org>
	<D18914EE-6430-48D8-A59F-CD2DD5A5AFD1@canonical.com>
	<1263920913.495.9.camel@alisah>
Message-ID: <5CD53356-0DD5-4045-BC9E-0E01C970EEE4@canonical.com>


On Jan 19, 2010, at 12:08 PM, Yonsy Solis wrote:

> On Tue, 2010-01-19 at 11:29 -0500, Gary Poster wrote:
> 
>> The new branch does not try for that.  It simply builds dependency sets ignoring the Python's site.py (so, ignoring site-packages).  If desired, you can have scripts import site.py *after* the buildout eggs have been set up (so if your buildout did not require PIL, but your system's Python had it, your code could use the system's version if you were willing to open yourself up to that potential fragility), but that's the only integration.
>> 
>> If it is really desired, I could look at porting the work later from the previous branch (after the basic work on the new approach lands).  I am currently of the opinion that it is too tricky for too rare of a win (and I don't need it right now ;-) ).
> 
> Gary, exist any way that this feature to exclude the site-packages can
> be coded like an buildout extension ?

Not that I see, no.  It needs changes that are at the heart of the buildout code, AFAIK.

Gary

From riccardo.maria.bianchi at cern.ch  Thu Jan 21 11:30:13 2010
From: riccardo.maria.bianchi at cern.ch (Riccardo-Maria BIANCHI)
Date: Thu, 21 Jan 2010 11:30:13 +0100
Subject: [Distutils] distutils Install.py and install folder
Message-ID: <4B582CB5.1070607@cern.ch>


Good morning,

I'm using distutils to package a tool, and I was thinking that it would 
be very useful to have the self.install_lib variable returned in some 
way to the user in the setup.py script, after the call of setup().

In that way the user could automate the creation of the .pth file in 
order to add the installed module folder to the python search path.
This is useful when the user wants to create a stand-alone package, 
working out of the box when unzipping it, without installation in the 
system site-packages/ folder.

The folder name used for the installation is written out on the screen 
at line 615 of the HEAD of Install.py:

===
log.debug(("modules installed to '%s', which is not in "
                      "Python's module search path (sys.path) -- "
                      "you'll have to change the search path yourself"),
                      self.install_lib)
===

So in some ways we could grab it from there and return it to the user.

Many thanks for your kind attention,

Best regards,

From ziade.tarek at gmail.com  Thu Jan 21 12:18:36 2010
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Thu, 21 Jan 2010 12:18:36 +0100
Subject: [Distutils] distutils Install.py and install folder
In-Reply-To: <4B582CB5.1070607@cern.ch>
References: <4B582CB5.1070607@cern.ch>
Message-ID: <94bdd2611001210318v5f756f2co7b68fe184dbbc1e1@mail.gmail.com>

On Thu, Jan 21, 2010 at 11:30 AM, Riccardo-Maria BIANCHI
<riccardo.maria.bianchi at cern.ch> wrote:
>
> Good morning,
>
> I'm using distutils to package a tool, and I was thinking that it would be
> very useful to have the self.install_lib variable returned in some way to
> the user in the setup.py script, after the call of setup().

setup() returns the distribution object, which have a
get_command_obj() function you can call to get back to the commands
that were run, therefore their options.

But I don't think you want to do this just to be able to run a
standalone distribution.

You can change the PYTHONPATH environment variable for what you need,
*or* use Distribute/Setuptools' "develop" command, that allows you to
run a distribution "inplace". It creates a special file in
site-package that is comparable to a symbolic link pointing to your
project.

Regards
Tarek

-- 
Tarek Ziad? | http://ziade.org

From ziade.tarek at gmail.com  Sat Jan 23 13:00:16 2010
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Sat, 23 Jan 2010 13:00:16 +0100
Subject: [Distutils] Distutils roadmap of refactoring for 2.7
Message-ID: <94bdd2611001230400sed23a0excc626c85cf6e39bb@mail.gmail.com>

Hello,

I've started to refactor a few things in Distutils for 2.7, as I
planned to do before the first 2.7 beta.

Here are the major ones FYI:

1- the "sysconfig" module is going to the stdlib, and changes a bit.
Almost all APIs are still present,
    and the ones that were removed are left in distutils.sysconfig and
marked as deprecated. (because they can
    be changed by calls to other APIs)

   IOW, all you have to do at this point for APIs that where moved is
to do "from sysconfig import xx"
   instead of "from distutils.sysconfig import xx"

2-   My next step is to document this new stdlib module in
docs.python.org and to add 2.7 support in Distribute so people can
work with
     2.7 if the want/need.

3 - dir_util, archive_util and file_util are going to be removed in
favor of calls to shutil.
    shutil is going to host two new functions: make_archive and
unpack_archive (the latter was introduced by setuptools)

4 - a standalone version of distutils, backward compatible with 2.5
and 2.6, that can be installed by itself, through pypi, is coming.
    I have no plan to support 2.4 unless someone strongly wants it.

1 is done already in trunk. and is going to be merged in py3 in a few
days. 2. 3. 4. should be done within the next week.

Regards
Tarek

-- 
Tarek Ziad? | http://ziade.org

From pje at telecommunity.com  Sat Jan 23 18:19:33 2010
From: pje at telecommunity.com (P.J. Eby)
Date: Sat, 23 Jan 2010 12:19:33 -0500
Subject: [Distutils] Distutils roadmap of refactoring for 2.7
In-Reply-To: <94bdd2611001230400sed23a0excc626c85cf6e39bb@mail.gmail.com
 >
References: <94bdd2611001230400sed23a0excc626c85cf6e39bb@mail.gmail.com>
Message-ID: <20100123171947.EBCC63A4065@sparrow.telecommunity.com>

At 01:00 PM 1/23/2010 +0100, Tarek Ziad? wrote:
>3 - dir_util, archive_util and file_util are going to be removed in
>favor of calls to shutil.

By removed, do you simply mean that distutils will stop using them, 
but the modules will still be there?  (i.e., deprecated and phased 
out, rather than simply dropped from existence altogether.)


From ziade.tarek at gmail.com  Sat Jan 23 18:29:25 2010
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Sat, 23 Jan 2010 18:29:25 +0100
Subject: [Distutils] Distutils roadmap of refactoring for 2.7
In-Reply-To: <20100123171947.EBCC63A4065@sparrow.telecommunity.com>
References: <94bdd2611001230400sed23a0excc626c85cf6e39bb@mail.gmail.com>
	<20100123171947.EBCC63A4065@sparrow.telecommunity.com>
Message-ID: <94bdd2611001230929n47ef1945h6c2e4ae3513b614b@mail.gmail.com>

2010/1/23 P.J. Eby <pje at telecommunity.com>:
> At 01:00 PM 1/23/2010 +0100, Tarek Ziad? wrote:
>>
>> 3 - dir_util, archive_util and file_util are going to be removed in
>> favor of calls to shutil.
>
> By removed, do you simply mean that distutils will stop using them, but the
> modules will still be there? ?(i.e., deprecated and phased out, rather than
> simply dropped from existence altogether.)

I'll use the same strategy than sysconfig :

- if the API is just moved to another place and works exactly the same way
  (e.g. like what's planned for make_archive), it will  be dropped, and the
  documentation will refer to the new place.

- if the API is removed for good, it'll follow a deprecation process

IOW the short term impact for Setuptools (and therefore Distribute)
will be to change a few imports for relocated APIs to be 2.7
compatible.

Tarek

From pje at telecommunity.com  Sat Jan 23 19:11:16 2010
From: pje at telecommunity.com (P.J. Eby)
Date: Sat, 23 Jan 2010 13:11:16 -0500
Subject: [Distutils] Distutils roadmap of refactoring for 2.7
In-Reply-To: <94bdd2611001230929n47ef1945h6c2e4ae3513b614b@mail.gmail.co
 m>
References: <94bdd2611001230400sed23a0excc626c85cf6e39bb@mail.gmail.com>
	<20100123171947.EBCC63A4065@sparrow.telecommunity.com>
	<94bdd2611001230929n47ef1945h6c2e4ae3513b614b@mail.gmail.com>
Message-ID: <20100123181126.AA2AE3A4065@sparrow.telecommunity.com>

At 06:29 PM 1/23/2010 +0100, Tarek Ziad? wrote:
>2010/1/23 P.J. Eby <pje at telecommunity.com>:
> > At 01:00 PM 1/23/2010 +0100, Tarek Ziad? wrote:
> >>
> >> 3 - dir_util, archive_util and file_util are going to be removed in
> >> favor of calls to shutil.
> >
> > By removed, do you simply mean that distutils will stop using them, but the
> > modules will still be there?  (i.e., deprecated and phased out, rather than
> > simply dropped from existence altogether.)
>
>I'll use the same strategy than sysconfig :
>
>- if the API is just moved to another place and works exactly the same way
>   (e.g. like what's planned for make_archive), it will  be dropped, and the
>   documentation will refer to the new place.

Is this the standard procedure for relocation of stdlib APIs across 
2.x releases?
I was under the impression that the standard is to do such things 
across two release cycles with a deprecation.


From ziade.tarek at gmail.com  Sat Jan 23 19:41:08 2010
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Sat, 23 Jan 2010 19:41:08 +0100
Subject: [Distutils] Distutils roadmap of refactoring for 2.7
In-Reply-To: <20100123181126.AA2AE3A4065@sparrow.telecommunity.com>
References: <94bdd2611001230400sed23a0excc626c85cf6e39bb@mail.gmail.com>
	<20100123171947.EBCC63A4065@sparrow.telecommunity.com>
	<94bdd2611001230929n47ef1945h6c2e4ae3513b614b@mail.gmail.com>
	<20100123181126.AA2AE3A4065@sparrow.telecommunity.com>
Message-ID: <94bdd2611001231041i45ec71qae737789cab2bf40@mail.gmail.com>

On Sat, Jan 23, 2010 at 7:11 PM, P.J. Eby <pje at telecommunity.com> wrote:
> At 06:29 PM 1/23/2010 +0100, Tarek Ziad? wrote:
>>
>> 2010/1/23 P.J. Eby <pje at telecommunity.com>:
>> > At 01:00 PM 1/23/2010 +0100, Tarek Ziad? wrote:
>> >>
>> >> 3 - dir_util, archive_util and file_util are going to be removed in
>> >> favor of calls to shutil.
>> >
>> > By removed, do you simply mean that distutils will stop using them, but
>> > the
>> > modules will still be there? ?(i.e., deprecated and phased out, rather
>> > than
>> > simply dropped from existence altogether.)
>>
>> I'll use the same strategy than sysconfig :
>>
>> - if the API is just moved to another place and works exactly the same way
>> ?(e.g. like what's planned for make_archive), it will ?be dropped, and the
>> ?documentation will refer to the new place.
>
> Is this the standard procedure for relocation of stdlib APIs across 2.x
> releases?
> I was under the impression that the standard is to do such things across two
> release cycles with a deprecation.

I was under the same impression at first (that's how I did at first
for distutils.sysconfig in my branch) but then MAL suggested in
python-dev that I could simply update the documentation for these
APIs, so I've followed that strategy.

Unlike micro releases, I don't think Distutils in 2.7 has to strictly
behave like in 2.6, API-wise, especially since a standalone backport
will be released for 2.6. Notice that other changes are coming up once
the series of PEP we worked on are accepted (which should be before
Pycon - at least for 345 and 386)

Tarek

-- 
Tarek Ziad? | http://ziade.org

From exarkun at twistedmatrix.com  Sat Jan 23 20:49:47 2010
From: exarkun at twistedmatrix.com (exarkun at twistedmatrix.com)
Date: Sat, 23 Jan 2010 19:49:47 -0000
Subject: [Distutils] Distutils roadmap of refactoring for 2.7
In-Reply-To: <94bdd2611001231041i45ec71qae737789cab2bf40@mail.gmail.com>
References: <94bdd2611001230400sed23a0excc626c85cf6e39bb@mail.gmail.com>
	<20100123171947.EBCC63A4065@sparrow.telecommunity.com>
	<94bdd2611001230929n47ef1945h6c2e4ae3513b614b@mail.gmail.com>
	<20100123181126.AA2AE3A4065@sparrow.telecommunity.com>
	<94bdd2611001231041i45ec71qae737789cab2bf40@mail.gmail.com>
Message-ID: <20100123194947.1898.2142254637.divmod.xquotient.588@localhost.localdomain>

On 06:41 pm, ziade.tarek at gmail.com wrote:
>On Sat, Jan 23, 2010 at 7:11 PM, P.J. Eby <pje at telecommunity.com> 
>wrote:
>>>I'll use the same strategy than sysconfig :
>>>
>>>- if the API is just moved to another place and works exactly the 
>>>same way
>>>?(e.g. like what's planned for make_archive), it will ?be dropped, 
>>>and the
>>>?documentation will refer to the new place.
>>
>>Is this the standard procedure for relocation of stdlib APIs across 
>>2.x
>>releases?
>>I was under the impression that the standard is to do such things 
>>across two
>>release cycles with a deprecation.
>
>I was under the same impression at first (that's how I did at first
>for distutils.sysconfig in my branch) but then MAL suggested in
>python-dev that I could simply update the documentation for these
>APIs, so I've followed that strategy.
>
>Unlike micro releases, I don't think Distutils in 2.7 has to strictly
>behave like in 2.6, API-wise, especially since a standalone backport
>will be released for 2.6. Notice that other changes are coming up once
>the series of PEP we worked on are accepted (which should be before
>Pycon - at least for 345 and 386)

There really is no standard for this.  The few times it's been raised on 
python-dev to create one, discussion has puttered out rather quickly 
with no resolution.

I think that if the people doing this work (so, largely Tarek at this 
point) want, though, they can decide on a specific policy for distutils. 
If so, this should be documented somewhere as well, so that people know 
what to expect when upgrading distutils somehow (either via a stand- 
alone package or with a new version of Python).

Jean-Paul

From regebro at gmail.com  Sun Jan 24 10:29:46 2010
From: regebro at gmail.com (Lennart Regebro)
Date: Sun, 24 Jan 2010 10:29:46 +0100
Subject: [Distutils] Distutils roadmap of refactoring for 2.7
In-Reply-To: <20100123194947.1898.2142254637.divmod.xquotient.588@localhost.localdomain>
References: <94bdd2611001230400sed23a0excc626c85cf6e39bb@mail.gmail.com>
	<20100123171947.EBCC63A4065@sparrow.telecommunity.com>
	<94bdd2611001230929n47ef1945h6c2e4ae3513b614b@mail.gmail.com>
	<20100123181126.AA2AE3A4065@sparrow.telecommunity.com>
	<94bdd2611001231041i45ec71qae737789cab2bf40@mail.gmail.com>
	<20100123194947.1898.2142254637.divmod.xquotient.588@localhost.localdomain>
Message-ID: <319e029f1001240129r4484bce8n891726b4f3e3e7ee@mail.gmail.com>

2010/1/23  <exarkun at twistedmatrix.com>:
> There really is no standard for this. ?The few times it's been raised on
> python-dev to create one, discussion has puttered out rather quickly with no
> resolution.
>
> I think that if the people doing this work (so, largely Tarek at this point)
> want, though, they can decide on a specific policy for distutils. If so,
> this should be documented somewhere as well, so that people know what to
> expect when upgrading distutils somehow (either via a stand- alone package
> or with a new version of Python).

I think deprecation is the ticket here. We don't want to force
everybody to have try/except imports or install the standalone version
just because of this. The standalone version should be if you need new
features, not just because you also want to work in Python 2.7.

-- 
Lennart Regebro: Python, Zope, Plone, Grok
http://regebro.wordpress.com/
+33 661 58 14 64

From david.lyon at pythontest.org  Mon Jan 25 04:38:36 2010
From: david.lyon at pythontest.org (David Lyon)
Date: Mon, 25 Jan 2010 14:38:36 +1100 (EST)
Subject: [Distutils] Distutils roadmap of refactoring for 2.7
In-Reply-To: <94bdd2611001231041i45ec71qae737789cab2bf40@mail.gmail.com>
References: <94bdd2611001230400sed23a0excc626c85cf6e39bb@mail.gmail.com>
	<20100123171947.EBCC63A4065@sparrow.telecommunity.com>
	<94bdd2611001230929n47ef1945h6c2e4ae3513b614b@mail.gmail.com>
	<20100123181126.AA2AE3A4065@sparrow.telecommunity.com>
	<94bdd2611001231041i45ec71qae737789cab2bf40@mail.gmail.com>
Message-ID: <1927.218.214.45.58.1264390716.squirrel@syd-srv02.ezyreg.com>

> On Sat, Jan 23, 2010 at 7:11 PM, P.J. Eby <pje at telecommunity.com> wrote:
> Notice that other changes are coming up once
> the series of PEP we worked on are accepted (which should be before
> Pycon - at least for 345 and 386)

ok - so are you going to sort out the confusing (i386 == mac)
and (x86 == pc) or (i586 == pc) or (i686 == pc) ?

in PEP-345? or leave it as downright confusing?

David



From lregebro at jarn.com  Mon Jan 25 13:43:05 2010
From: lregebro at jarn.com (Lennart Regebro)
Date: Mon, 25 Jan 2010 13:43:05 +0100
Subject: [Distutils] [Python-Dev] Rich Comparison recipe wrong?
In-Reply-To: <dfbefb091001250426i48a31cbckdc27ead57646be9c@mail.gmail.com>
References: <319e029f1001250359j4e78807aub8397fcd09fcc561@mail.gmail.com>
	<dfbefb091001250426i48a31cbckdc27ead57646be9c@mail.gmail.com>
Message-ID: <319e029f1001250443h302af8f6w3e000a1b954c136@mail.gmail.com>

2010/1/25 ?ukasz Rekucki <lrekucki at gmail.com>:
> No, cause what the snippet does is: *not B.__lt__(A)* which is
> mathematicly correct and doesn't require A to implement anything.

Yes, sorry, it's when you do a > b the problem arises.

1. a > b first tries a.__gt__(b)
2. b.__gt__(b) in turn does  b < a
3. Python's first attempt of b < a is calling b.__lt__(a)
4. but b.__lt__(a) returns NotImplemented
5. Python then tries the opposite, which is a.__gt__(b)
6. Goto 2

Infinite recursion.

From lregebro at jarn.com  Mon Jan 25 13:56:50 2010
From: lregebro at jarn.com (Lennart Regebro)
Date: Mon, 25 Jan 2010 13:56:50 +0100
Subject: [Distutils] [Python-Dev] Rich Comparison recipe wrong?
In-Reply-To: <319e029f1001250443h302af8f6w3e000a1b954c136@mail.gmail.com>
References: <319e029f1001250359j4e78807aub8397fcd09fcc561@mail.gmail.com>
	<dfbefb091001250426i48a31cbckdc27ead57646be9c@mail.gmail.com>
	<319e029f1001250443h302af8f6w3e000a1b954c136@mail.gmail.com>
Message-ID: <319e029f1001250456o4dc05d75u7c7f7fde5d6e5e3c@mail.gmail.com>

On Mon, Jan 25, 2010 at 13:43, Lennart Regebro <lregebro at jarn.com> wrote:
> 2010/1/25 ?ukasz Rekucki <lrekucki at gmail.com>:
>> No, cause what the snippet does is: *not B.__lt__(A)* which is
>> mathematicly correct and doesn't require A to implement anything.
>
> Yes, sorry, it's when you do a > b the problem arises.

and well, a != b, a == b and a <= b

But a < b works.

From tmohr at s.netic.de  Mon Jan 25 23:22:17 2010
From: tmohr at s.netic.de (Torsten Mohr)
Date: Mon, 25 Jan 2010 23:22:17 +0100
Subject: [Distutils] C extension modules
Message-ID: <201001252322.17838.tmohr@s.netic.de>

Hello,

i'm not sure if this is the preferred way to get help.  If it is not, can you 
then please tell me how?

I write a C++ extension module in which i need to tell if i compile on Linux 
or Windows.  What is the preferred way to do this?

Also, i use libjpeg, libtiff and libpng.  Can i portably test for presence and 
version of these libs on Linux, Windows and other OSes?

The documentation on docs.python.org is quite good, but are there some 
additional examples available?


Thanks for any hints,
Torsten.

From lregebro at jarn.com  Tue Jan 26 17:18:45 2010
From: lregebro at jarn.com (Lennart Regebro)
Date: Tue, 26 Jan 2010 17:18:45 +0100
Subject: [Distutils] "Error: Picked: distribute = 0.6.10"
Message-ID: <319e029f1001260818q2fdd30e2j88625d764f37f772@mail.gmail.com>

OK,I get this when running the buildout for manuel:

  Error: Picked: distribute = 0.6.10

 Why is that an error, exactly? What does it mean?

-- 
Lennart Regebro: Python, Zope, Plone, Grok
http://regebro.wordpress.com/
+33 661 58 14 64

From ziade.tarek at gmail.com  Tue Jan 26 17:25:31 2010
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Tue, 26 Jan 2010 17:25:31 +0100
Subject: [Distutils] "Error: Picked: distribute = 0.6.10"
In-Reply-To: <319e029f1001260818q2fdd30e2j88625d764f37f772@mail.gmail.com>
References: <319e029f1001260818q2fdd30e2j88625d764f37f772@mail.gmail.com>
Message-ID: <94bdd2611001260825m52fd3278hbcd24a21ed4e96f6@mail.gmail.com>

On Tue, Jan 26, 2010 at 5:18 PM, Lennart Regebro <lregebro at jarn.com> wrote:
> OK,I get this when running the buildout for manuel:
>

what's "for manuel" ?

> ?Error: Picked: distribute = 0.6.10
>
> ?Why is that an error, exactly? What does it mean?
>

Can you provide more information ? It's hard to tell what's going on
without knowing
how you bootstrapped your buildout and what's in your cfg


> --
> Lennart Regebro: Python, Zope, Plone, Grok
> http://regebro.wordpress.com/
> +33 661 58 14 64
> _______________________________________________
> Distutils-SIG maillist ?- ?Distutils-SIG at python.org
> http://mail.python.org/mailman/listinfo/distutils-sig
>



-- 
Tarek Ziad? | http://ziade.org

From benji at zope.com  Tue Jan 26 17:29:24 2010
From: benji at zope.com (Benji York)
Date: Tue, 26 Jan 2010 11:29:24 -0500
Subject: [Distutils] "Error: Picked: distribute = 0.6.10"
In-Reply-To: <319e029f1001260818q2fdd30e2j88625d764f37f772@mail.gmail.com>
References: <319e029f1001260818q2fdd30e2j88625d764f37f772@mail.gmail.com>
Message-ID: <e5fff6641001260829v49280e56uf1ed2451a502c8a9@mail.gmail.com>

On Tue, Jan 26, 2010 at 11:18 AM, Lennart Regebro <lregebro at jarn.com> wrote:
> OK,I get this when running the buildout for manuel:
>
> ?Error: Picked: distribute = 0.6.10
>
> ?Why is that an error, exactly? What does it mean?

I suspect it is an interaction of zc.buildout's allow-picked-versions =
false option and the fact that Distribute impersonates setuptools.

I bet it'll work properly if you add "distribute = 0.6.10" to the
[versions] section.
-- 
Benji York

From ziade.tarek at gmail.com  Tue Jan 26 17:32:37 2010
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Tue, 26 Jan 2010 17:32:37 +0100
Subject: [Distutils] C extension modules
In-Reply-To: <201001252322.17838.tmohr@s.netic.de>
References: <201001252322.17838.tmohr@s.netic.de>
Message-ID: <94bdd2611001260832sf9ed117p13d12c62593a82ad@mail.gmail.com>

On Mon, Jan 25, 2010 at 11:22 PM, Torsten Mohr <tmohr at s.netic.de> wrote:
> Hello,
>
> i'm not sure if this is the preferred way to get help. ?If it is not, can you
> then please tell me how?

That's the best way :)

>
> I write a C++ extension module in which i need to tell if i compile on Linux
> or Windows. ?What is the preferred way to do this?

What are you doing exactly with this information ?

>
> Also, i use libjpeg, libtiff and libpng. ?Can i portably test for presence and
> version of these libs on Linux, Windows and other OSes?
>
> The documentation on docs.python.org is quite good, but are there some
> additional examples available?

What's usually done is testing for the platform in setup.py to decide which
extensions are going in.

see http://bitbucket.org/kang/python-keyring-lib/src/  and in
particular "extensions.py" used in setup.py

Regards
Tarek

>
>
> Thanks for any hints,
> Torsten.
> _______________________________________________
> Distutils-SIG maillist ?- ?Distutils-SIG at python.org
> http://mail.python.org/mailman/listinfo/distutils-sig
>



-- 
Tarek Ziad? | http://ziade.org

From regebro at gmail.com  Tue Jan 26 17:53:24 2010
From: regebro at gmail.com (Lennart Regebro)
Date: Tue, 26 Jan 2010 17:53:24 +0100
Subject: [Distutils] distribute 0.6.10 and convert_2to3_doctests
In-Reply-To: <319e029f1001070534j44556099x89d5029aac9d67e9@mail.gmail.com>
References: <20100106181718.2a506964@freewill>
	<319e029f1001070309kba96eb8ha8031d2dfd285844@mail.gmail.com>
	<F059AED4-FD82-44D6-A128-5D80DE2A335C@python.org>
	<319e029f1001070534j44556099x89d5029aac9d67e9@mail.gmail.com>
Message-ID: <319e029f1001260853x4697afdo252e45f5938028a9@mail.gmail.com>

On Thu, Jan 7, 2010 at 14:34, Lennart Regebro <regebro at gmail.com> wrote:
> The next problem is that the tests seem to be run on the original, and
> not on the build-copy. And why that is, I don't know, and I have to
> debug that, which I can't do right now. I'll try tonight or tomorrow.
> It's most likely a bug in Distribute.

Well, kinda. :)

The problem is this code in setup.py:

    from munepy import __version__

That means munepy is already imported, so when it then looks for the
tests to run, it will import it from the already imported munepy
module. Changing it to

    from munepy import __version__
    del sys.modules['munepy']

Goes around the problem, but it's admittedly not a pretty fix.
I'm sure others will be bitten by this too. I'm not sure what a good
fix would be, except possibly removing all modules specified in
setup.py from sys.modules before running any commands.

-- 
Lennart Regebro: Python, Zope, Plone, Grok
http://regebro.wordpress.com/
+33 661 58 14 64

From lregebro at jarn.com  Tue Jan 26 17:56:01 2010
From: lregebro at jarn.com (Lennart Regebro)
Date: Tue, 26 Jan 2010 17:56:01 +0100
Subject: [Distutils] "Error: Picked: distribute = 0.6.10"
In-Reply-To: <e5fff6641001260829v49280e56uf1ed2451a502c8a9@mail.gmail.com>
References: <319e029f1001260818q2fdd30e2j88625d764f37f772@mail.gmail.com>
	<e5fff6641001260829v49280e56uf1ed2451a502c8a9@mail.gmail.com>
Message-ID: <319e029f1001260856y6bb1fc92l2237fac6633e5c16@mail.gmail.com>

On Tue, Jan 26, 2010 at 17:29, Benji York <benji at zope.com> wrote:
> I suspect it is an interaction of zc.buildout's allow-picked-versions =
> false option and the fact that Distribute impersonates setuptools.

Yup, that's it.

> I bet it'll work properly if you add "distribute = 0.6.10" to the
> [versions] section.

Yup! Thanks!

-- 
Lennart Regebro: Python, Zope, Plone, Grok
http://regebro.wordpress.com/
+33 661 58 14 64

From tmohr at s.netic.de  Tue Jan 26 18:30:33 2010
From: tmohr at s.netic.de (Torsten Mohr)
Date: Tue, 26 Jan 2010 18:30:33 +0100
Subject: [Distutils] C extension modules
In-Reply-To: <94bdd2611001260832sf9ed117p13d12c62593a82ad@mail.gmail.com>
References: <201001252322.17838.tmohr@s.netic.de>
	<94bdd2611001260832sf9ed117p13d12c62593a82ad@mail.gmail.com>
Message-ID: <201001261830.33502.tmohr@s.netic.de>

Hello Tarek,

great, good to know i can get some help here.

> > I write a C++ extension module in which i need to tell if i compile on
> > Linux or Windows.  What is the preferred way to do this?
> 
> What are you doing exactly with this information ?

Basically what i try to do is write an extension module in C++ for Python.
In the source code there are some parts for 
#ifdef HOST_MSWin32 and also for #ifdef HOST_linux.

I already got an idea, as setup.py is normal pyhton code i could try os.name .
That could help distinguishing in setup.py.  But i'm not sure on how to
forward this information so it is available in the source code.
It could be also something like #ifdef HOST_posix or HOST_nt .

What is the preferred way to make this information available to the compiler
so i can use code like #ifdef HOST_posix?

After looking in the documentation i found "define_macros", seems like the way 
to go, right?



Another thing that i'm not sure about is that i need to use other C libraries
from that module i write.  For example i want to load JPEG files, so i need
to find the header for libjpeg.h and also to link libjpeg to my module.

If i write a configure script (autoconf / autotools) there are code snippets 
to test for libraries and paths (to find the library and to set the include 
path).  Also to test for a certain version.

Is that possible to use in distutils / setup.py?

That link you gave below is a good example, the bad news is that i have to 
program a part for each OS.


Thanks a lot for your hints.  If any of the above is wrong then please correct 
me.


Best regards,
Torsten.


Am Dienstag, 26. Januar 2010 17:32:37 schrieb Tarek Ziad?:
> On Mon, Jan 25, 2010 at 11:22 PM, Torsten Mohr <tmohr at s.netic.de> wrote:
> > Hello,
> >
> > i'm not sure if this is the preferred way to get help.  If it is not, can
> > you then please tell me how?
> 
> That's the best way :)
> 
> 
> > Also, i use libjpeg, libtiff and libpng.  Can i portably test for
> > presence and version of these libs on Linux, Windows and other OSes?
> >
> > The documentation on docs.python.org is quite good, but are there some
> > additional examples available?
> 
> What's usually done is testing for the platform in setup.py to decide which
> extensions are going in.
> 
> see http://bitbucket.org/kang/python-keyring-lib/src/  and in
> particular "extensions.py" used in setup.py
> 
> Regards
> Tarek
> 
> > Thanks for any hints,
> > Torsten.
> > _______________________________________________
> > Distutils-SIG maillist  -  Distutils-SIG at python.org
> > http://mail.python.org/mailman/listinfo/distutils-sig
> 

From floris.bruynooghe at gmail.com  Tue Jan 26 18:46:43 2010
From: floris.bruynooghe at gmail.com (Floris Bruynooghe)
Date: Tue, 26 Jan 2010 17:46:43 +0000
Subject: [Distutils] C extension modules
In-Reply-To: <201001252322.17838.tmohr@s.netic.de>
References: <201001252322.17838.tmohr@s.netic.de>
Message-ID: <20100126174643.GA28891@laurie.devork>

Hi Torsten

On Mon, Jan 25, 2010 at 11:22:17PM +0100, Torsten Mohr wrote:
> i'm not sure if this is the preferred way to get help.  If it is
> not, can you then please tell me how?

This is the right place, comp.lang.python might work too.

> I write a C++ extension module in which i need to tell if i compile on Linux 
> or Windows.  What is the preferred way to do this?

Use one of platform.system() or sys.platform, depending on the lowest
verion of python you want to support.

> Also, i use libjpeg, libtiff and libpng.  Can i portably test for
> presence and version of these libs on Linux, Windows and other OSes?

Not really.  There is distutils.ccompiler.find_library_file() and
friends which you might put to good use, but I've never seen it being
used or used it myself.  And it's quite complicated to get a usable
instance of CCompiler, expect to read distutils source.

But generally you can just use the platform default includes and then
it will simply fail to compile if they're not present.


Regards
Floris

-- 
Debian GNU/Linux -- The Power of Freedom
www.debian.org | www.gnu.org | www.kernel.org

From ziade.tarek at gmail.com  Tue Jan 26 18:49:45 2010
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Tue, 26 Jan 2010 18:49:45 +0100
Subject: [Distutils] C extension modules
In-Reply-To: <201001261830.33502.tmohr@s.netic.de>
References: <201001252322.17838.tmohr@s.netic.de>
	<94bdd2611001260832sf9ed117p13d12c62593a82ad@mail.gmail.com>
	<201001261830.33502.tmohr@s.netic.de>
Message-ID: <94bdd2611001260949u74dc366dy8136a62d14188561@mail.gmail.com>

On Tue, Jan 26, 2010 at 6:30 PM, Torsten Mohr <tmohr at s.netic.de> wrote:
> Hello Tarek,
>
> great, good to know i can get some help here.
>
>> > I write a C++ extension module in which i need to tell if i compile on
>> > Linux or Windows. ?What is the preferred way to do this?
>>
>> What are you doing exactly with this information ?
>
> Basically what i try to do is write an extension module in C++ for Python.
> In the source code there are some parts for
> #ifdef HOST_MSWin32 and also for #ifdef HOST_linux.
>
> I already got an idea, as setup.py is normal pyhton code i could try os.name .
> That could help distinguishing in setup.py. ?But i'm not sure on how to
> forward this information so it is available in the source code.
> It could be also something like #ifdef HOST_posix or HOST_nt .
>
> What is the preferred way to make this information available to the compiler
> so i can use code like #ifdef HOST_posix?
>
> After looking in the documentation i found "define_macros", seems like the way
> to go, right?

Yes that's the way to pass values e.g. :

host = 'HOST_%s' % os.name

Extension('foo', .., define_macros=[(host, '1')])

But I wonder if there is no simple way for this particular need
(platform detection from within a C extension)

Tarek

From cournape at gmail.com  Wed Jan 27 02:57:37 2010
From: cournape at gmail.com (David Cournapeau)
Date: Wed, 27 Jan 2010 10:57:37 +0900
Subject: [Distutils] C extension modules
In-Reply-To: <201001261830.33502.tmohr@s.netic.de>
References: <201001252322.17838.tmohr@s.netic.de>
	<94bdd2611001260832sf9ed117p13d12c62593a82ad@mail.gmail.com>
	<201001261830.33502.tmohr@s.netic.de>
Message-ID: <5b8d13221001261757m4d469173gdfe69ea63839f71d@mail.gmail.com>

On Wed, Jan 27, 2010 at 2:30 AM, Torsten Mohr <tmohr at s.netic.de> wrote:

>
> What is the preferred way to make this information available to the compiler
> so i can use code like #ifdef HOST_posix?

Use a config.h, like autoconf does. Distutils does not make it for
you, and plugging the necessary code in distutils to do it is a PITA,
but that's doable.

Basically, you need to extend the distutils config command, and goes from there:

import sys
from distutils.core import setup
from distutils.command.config import config

def generate_config_h(filename, defs):
    with open(filename, "w") as fid:
        fid.write("#ifndef HAVE_CONFIG_H\n")
        fid.write("#define HAVE_CONFIG_H\n\n")

        for d in defs:
            if isinstance(d, str):
                fid.write("#define %s\n" % d)
            else:
                fid.write("#define %s %s\n" % (d[0], d[1]))
        fid.write("\n#endif\n")

class MyConfig(config):
    def check_headers(self, headers=None):
        if headers is None:
            headers = []

        body = """\
/* Some stupid comment because distutils does not accept empty body */
"""
        return self.try_compile(body, headers)

    def run(self):
        defines = []
        if self.check_headers(["stdio.h"]):
            defines.append(("HAVE_STDIO_H", 1))
        if self.check_headers(["stdlib.h"]):
            defines.append(("HAVE_STDLIB_H", 1))

        if sys.platform == "win32":
            defines.append(("FOO_OS_WIN32", 1))
        else:
            defines.append(("FOO_OS_POSIX", 1))
        generate_config_h("config.h", defines)

setup(name="yo", cmdclass={"config": MyConfig})

Once config is run by distutils, you end up with a config.h that you
will then import in your extensions. The fun starts when you need to
deal with build directories and the like,

cheers,

David

From floris.bruynooghe at gmail.com  Wed Jan 27 10:58:35 2010
From: floris.bruynooghe at gmail.com (Floris Bruynooghe)
Date: Wed, 27 Jan 2010 09:58:35 +0000
Subject: [Distutils] C extension modules
In-Reply-To: <5b8d13221001261757m4d469173gdfe69ea63839f71d@mail.gmail.com>
References: <201001252322.17838.tmohr@s.netic.de>
	<94bdd2611001260832sf9ed117p13d12c62593a82ad@mail.gmail.com>
	<201001261830.33502.tmohr@s.netic.de>
	<5b8d13221001261757m4d469173gdfe69ea63839f71d@mail.gmail.com>
Message-ID: <20100127095835.GA19355@laurie.devork>

On Wed, Jan 27, 2010 at 10:57:37AM +0900, David Cournapeau wrote:
> On Wed, Jan 27, 2010 at 2:30 AM, Torsten Mohr <tmohr at s.netic.de> wrote:
> > What is the preferred way to make this information available to
> > the compiler so i can use code like #ifdef HOST_posix?
> 
> Use a config.h, like autoconf does. Distutils does not make it for
> you, and plugging the necessary code in distutils to do it is a PITA,
> but that's doable.
> 
> Basically, you need to extend the distutils config command, and goes
> from there:

Neat, I didn't know that command existed.

> class MyConfig(config):
>     def check_headers(self, headers=None):

Why do you define this yourself?  The base config class already
defines .check_header() that looks like it does the same (only one
header at a time rather then multiple).

Also, does anyone have an idea why config.check_func() and
CCompiler.has_function() basically seem to be doing the same?


Regards
Floris

-- 
Debian GNU/Linux -- The Power of Freedom
www.debian.org | www.gnu.org | www.kernel.org

From cournape at gmail.com  Wed Jan 27 11:06:43 2010
From: cournape at gmail.com (David Cournapeau)
Date: Wed, 27 Jan 2010 19:06:43 +0900
Subject: [Distutils] C extension modules
In-Reply-To: <20100127095835.GA19355@laurie.devork>
References: <201001252322.17838.tmohr@s.netic.de>
	<94bdd2611001260832sf9ed117p13d12c62593a82ad@mail.gmail.com>
	<201001261830.33502.tmohr@s.netic.de>
	<5b8d13221001261757m4d469173gdfe69ea63839f71d@mail.gmail.com>
	<20100127095835.GA19355@laurie.devork>
Message-ID: <5b8d13221001270206u20ebc972m6a8f00c8867839ba@mail.gmail.com>

On Wed, Jan 27, 2010 at 6:58 PM, Floris Bruynooghe
<floris.bruynooghe at gmail.com> wrote:
> On Wed, Jan 27, 2010 at 10:57:37AM +0900, David Cournapeau wrote:
>> On Wed, Jan 27, 2010 at 2:30 AM, Torsten Mohr <tmohr at s.netic.de> wrote:
>> > What is the preferred way to make this information available to
>> > the compiler so i can use code like #ifdef HOST_posix?
>>
>> Use a config.h, like autoconf does. Distutils does not make it for
>> you, and plugging the necessary code in distutils to do it is a PITA,
>> but that's doable.
>>
>> Basically, you need to extend the distutils config command, and goes
>> from there:
>
> Neat, I didn't know that command existed.
>
>> class MyConfig(config):
>> ? ? def check_headers(self, headers=None):
>
> Why do you define this yourself?

That was just meant as an illustrative purpose - I do not recommend to
code things as is :) Note that in practice, this is actually difficult
to use for non trivial stuff, because the MyConfig class runs in a
difference context than the setup call.

> Also, does anyone have an idea why config.check_func() and
> CCompiler.has_function() basically seem to be doing the same?

Those kind of redundancies are common in distutils - often, they have
some small differences in how build directories are set, or things
like that, although I was not aware of this redundancy (I avoid
CCompiler functions like the plague in numpy.distutils extensions,
because their behavior is very platform specific, especially between
MS compiler and Unix ones, where the attributes are not the same).

David

From ziade.tarek at gmail.com  Wed Jan 27 12:00:10 2010
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Wed, 27 Jan 2010 12:00:10 +0100
Subject: [Distutils] C extension modules
In-Reply-To: <5b8d13221001270206u20ebc972m6a8f00c8867839ba@mail.gmail.com>
References: <201001252322.17838.tmohr@s.netic.de>
	<94bdd2611001260832sf9ed117p13d12c62593a82ad@mail.gmail.com>
	<201001261830.33502.tmohr@s.netic.de>
	<5b8d13221001261757m4d469173gdfe69ea63839f71d@mail.gmail.com>
	<20100127095835.GA19355@laurie.devork>
	<5b8d13221001270206u20ebc972m6a8f00c8867839ba@mail.gmail.com>
Message-ID: <94bdd2611001270300x2ac26e9bo47a2afee7d26cb43@mail.gmail.com>

On Wed, Jan 27, 2010 at 11:06 AM, David Cournapeau <cournape at gmail.com> wrote:
[..]
> I avoid CCompiler functions like the plague in numpy.distutils extensions,
> because their behavior is very platform specific, especially between
> MS compiler and Unix ones, where the attributes are not the same).

I am not an expert at all in compiling C/C++ for Python, but it seems
that using 'define_macros' works for what was asked.

So how do you do it in numpy.distutils and why/how is it better or simpler?

Regards,
Tarek

From cournape at gmail.com  Wed Jan 27 15:50:57 2010
From: cournape at gmail.com (David Cournapeau)
Date: Wed, 27 Jan 2010 23:50:57 +0900
Subject: [Distutils] C extension modules
In-Reply-To: <94bdd2611001270300x2ac26e9bo47a2afee7d26cb43@mail.gmail.com>
References: <201001252322.17838.tmohr@s.netic.de>
	<94bdd2611001260832sf9ed117p13d12c62593a82ad@mail.gmail.com>
	<201001261830.33502.tmohr@s.netic.de>
	<5b8d13221001261757m4d469173gdfe69ea63839f71d@mail.gmail.com>
	<20100127095835.GA19355@laurie.devork>
	<5b8d13221001270206u20ebc972m6a8f00c8867839ba@mail.gmail.com>
	<94bdd2611001270300x2ac26e9bo47a2afee7d26cb43@mail.gmail.com>
Message-ID: <5b8d13221001270650r17005c1fq51a4fca752d39fa2@mail.gmail.com>

On Wed, Jan 27, 2010 at 8:00 PM, Tarek Ziad? <ziade.tarek at gmail.com> wrote:
> On Wed, Jan 27, 2010 at 11:06 AM, David Cournapeau <cournape at gmail.com> wrote:
> [..]
>> I avoid CCompiler functions like the plague in numpy.distutils extensions,
>> because their behavior is very platform specific, especially between
>> MS compiler and Unix ones, where the attributes are not the same).
>
> I am not an expert at all in compiling C/C++ for Python, but it seems
> that using 'define_macros' works for what was asked.

It does work, but I believe that's kludgy once you have more than a
few macros (it cluttered the output, you may end up having too long
command lines, etc...). It is also useful to have one config.h which
is then included in a myconfig.h which customize some macro depending
on config.h, for example to bypass automatic configuration for some
special cases.

>
> So how do you do it in numpy.distutils and why/how is it better or simpler?

We just extend the config command with our own functions - nothing
particular, mostly duct tape to deal with correct initialization of
our own extensions (fortran, etc...). The biggest issue is the
different context I have mentioned: you can only configure things in
the config command context, which means it cannot affect the setup
arguments. Though I guess that's only a problem for big projects.

David

From tmohr at s.netic.de  Thu Jan 28 00:51:03 2010
From: tmohr at s.netic.de (Torsten Mohr)
Date: Thu, 28 Jan 2010 00:51:03 +0100
Subject: [Distutils] C extension modules
In-Reply-To: <20100126174643.GA28891@laurie.devork>
References: <201001252322.17838.tmohr@s.netic.de>
	<20100126174643.GA28891@laurie.devork>
Message-ID: <201001280051.03665.tmohr@s.netic.de>

Hello,

thank you all for your hints.  I've created a setup.py and can compile my C++ 
extension module now.

> > Also, i use libjpeg, libtiff and libpng.  Can i portably test for
> > presence and version of these libs on Linux, Windows and other OSes?
> 
> Not really.  There is distutils.ccompiler.find_library_file() and
> friends which you might put to good use, but I've never seen it being
> used or used it myself.  And it's quite complicated to get a usable
> instance of CCompiler, expect to read distutils source.
> 
> But generally you can just use the platform default includes and then
> it will simply fail to compile if they're not present.

But when using:

libraries = [ 'jpeg', 'png', 'tiff']

Then the dynamic libraries are linked, which i not necessarily want.
Using names line libjpeg.a seems to work but is not portable.

In distutils.ccompiler it seems in CCompiler() there is something like 
"library_filename()", has anybody got an example?  Or is there a better 
solution?


Best regards,
Torsten.

From sridharr at activestate.com  Thu Jan 28 20:32:33 2010
From: sridharr at activestate.com (Sridhar Ratnakumar)
Date: Thu, 28 Jan 2010 11:32:33 -0800
Subject: [Distutils] Buildout: Including another Python project via
	mercurial?
Message-ID: <4B61E651.3020600@activestate.com>

I originally posted this in Stackoverflow: 
http://stackoverflow.com/questions/2150887

Here's my buildout.cfg:

     [buildout]
     parts = ... pyrtm ...
     develop = . parts/pyrtm
     eggs = pyrtm

     [pyrtm]
     recipe = mercurialrecipe
     repository = http://bitbucket.org/srid/pyrtm

     ...

Assume that `pyrtm' has a release on PyPI, but I don't wish to use that. 
What I want here is to use the pyrtm from hg repository directly in my 
current project. This means:

1/ if I do "import pyrtm", it should use the pyrtm in the local checkout 
(not from pypi release)

2/ Automatically fetch the dependencies (install_requires) of pyrtm when 
I run bin/buildout. (otherwise, pyrtm wouldn't work. doh!)

The above buildout.cfg does none of the above. How do I make it work as 
intended?

Note that `pyrtm' actually does not have any dependencies and I used it 
as an example only (In actuality, I want to rely on an internal package 
that has several installation requirements).

Lennart originally suggested the "develop =" syntax which, as shown 
above, does not work. Any ideas?

-srid

From jon at multani.info  Thu Jan 28 23:57:19 2010
From: jon at multani.info (Jonathan Ballet)
Date: Thu, 28 Jan 2010 22:57:19 +0000
Subject: [Distutils] Buildout: Including another Python project via
 mercurial?
In-Reply-To: <4B61E651.3020600@activestate.com>
References: <4B61E651.3020600@activestate.com>
Message-ID: <20100128225719.0d9da9cb@gourami>

Hello,

Le Thu, 28 Jan 2010 11:32:33 -0800, Sridhar Ratnakumar
<sridharr at activestate.com> a ?crit :

> The above buildout.cfg does none of the above. How do I make it work as 
> intended?

For this particular usage, I would either:

* Clone the repository by myself, and develop it using Buildout's develop
  option. This can be summarized like that::

    $ hg clone http://bitbucket.org/srid/pyrtm pyrtm-repository
    $ cat buildout.cfg
    [buildout]
    develop = pyrtm-repository
    parts = part-that-need-pyrtm

    [part-that-need-pyrtm]
    recipe = zc.recipe.egg
    eggs = pyrtm

* Use mr.developer [1] to automate this. I didn't find it very useful, though,
  but this is closer to what you like to do using mercurialrecipe, despite
  mr.developer looks more active and I know several developers which are using
  it. It also has a comprehensive documentation, which mercurialrecipe doesn't
  have!

Speaking for myself, I'm using the first option several times a day. The
"schemes" extension, which is part of Mercurial > 1.4.1, is a bless: I created
a shortcut which points to our internal repository, and so, I don't have to
enter the full URL (scheme + domain name + directories) of the component, only
"sact://foo.bar" ("sact://" is my custom scheme).

> Note that `pyrtm' actually does not have any dependencies and I used it 
> as an example only (In actuality, I want to rely on an internal package 
> that has several installation requirements).
> 
> Lennart originally suggested the "develop =" syntax which, as shown 
> above, does not work. Any ideas?

I don't know how mercurialrecipe works, so I can't help you on this. Maybe the
output of Buildout may help us? (also, have a look at the output using multiple
-v and buildout:log-level=debug option)

Regards,

 Jonathan

[1]: http://pypi.python.org/pypi/mr.developer

From david.lyon at pythontest.org  Thu Jan 28 23:12:13 2010
From: david.lyon at pythontest.org (David Lyon)
Date: Fri, 29 Jan 2010 09:12:13 +1100 (EST)
Subject: [Distutils] Buildout: Including another Python project via
 mercurial?
In-Reply-To: <4B61E651.3020600@activestate.com>
References: <4B61E651.3020600@activestate.com>
Message-ID: <37779.115.128.24.122.1264716733.squirrel@syd-srv02.ezyreg.com>


Hi Srid,


> I originally posted this in Stackoverflow:
> http://stackoverflow.com/questions/2150887
>
> Here's my buildout.cfg:
>
> ..
>      [pyrtm]
>      recipe = mercurialrecipe
>      repository = http://bitbucket.org/srid/pyrtm
>
>      ...
>
> Assume that `pyrtm' has a release on PyPI, but I don't wish to use that.
> What I want here is to use the pyrtm from hg repository directly in my
> current project. This means:
>
> 1/ if I do "import pyrtm", it should use the pyrtm in the local checkout
> (not from pypi release)
>
> 2/ Automatically fetch the dependencies (install_requires) of pyrtm when
> I run bin/buildout. (otherwise, pyrtm wouldn't work. doh!)
>
> The above buildout.cfg does none of the above. How do I make it work as
> intended?

Do you want buildout fixed ? or can you add your own code?

Here's a simple way to use hg, change it easily to do a clone etc:

    http://stackoverflow.com/questions/1153469/mercurial-scripting-with-python

David



From sridharr at activestate.com  Fri Jan 29 02:47:51 2010
From: sridharr at activestate.com (Sridhar Ratnakumar)
Date: Thu, 28 Jan 2010 17:47:51 -0800
Subject: [Distutils] Buildout: Including another Python project via
	mercurial?
In-Reply-To: <20100128225719.0d9da9cb@gourami>
References: <4B61E651.3020600@activestate.com>
	<20100128225719.0d9da9cb@gourami>
Message-ID: <4B623E47.7020800@activestate.com>

On 1/28/2010 2:57 PM, Jonathan Ballet wrote:
> Hello,
>
> Le Thu, 28 Jan 2010 11:32:33 -0800, Sridhar Ratnakumar
> <sridharr at activestate.com>  a ?crit :
>
>> >  The above buildout.cfg does none of the above. How do I make it work as
>> >  intended?
> For this particular usage, I would either:
>
> * Clone the repository by myself, and develop it using Buildout's develop
>    option. This can be summarized like that::
>
>      $ hg clonehttp://bitbucket.org/srid/pyrtm  pyrtm-repository
>      $ cat buildout.cfg
>      [buildout]
>      develop = pyrtm-repository
>      parts = part-that-need-pyrtm
>
>      [part-that-need-pyrtm]
>      recipe = zc.recipe.egg
>      eggs = pyrtm

Yes, this works (but not 100% flawlessly with mercurialrecipe).

> * Use mr.developer [1] to automate this. I didn't find it very useful, though,
>    but this is closer to what you like to do using mercurialrecipe, despite
>    mr.developer looks more active and I know several developers which are using
>    it. It also has a comprehensive documentation, which mercurialrecipe doesn't
>    have!

This too works. mr.developer 1.9 is buggy and I had to pin version 1.7. 
But I prefer the first option which sounds simpler to me.

> Speaking for myself, I'm using the first option several times a day. The
> "schemes" extension, which is part of Mercurial>  1.4.1, is a bless: I created
> a shortcut which points to our internal repository, and so, I don't have to
> enter the full URL (scheme + domain name + directories) of the component, only
> "sact://foo.bar" ("sact://" is my custom scheme).

But doesn't manually cloning your dependent repositories beat the idea 
of build automation?

>> >  Note that `pyrtm' actually does not have any dependencies and I used it
>> >  as an example only (In actuality, I want to rely on an internal package
>> >  that has several installation requirements).
>> >
>> >  Lennart originally suggested the "develop =" syntax which, as shown
>> >  above, does not work. Any ideas?
> I don't know how mercurialrecipe works, so I can't help you on this. Maybe the
> output of Buildout may help us? (also, have a look at the output using multiple
> -v and buildout:log-level=debug option)

mercurialreciple only does "hg clone". It does not automatically make it 
a develop egg. When I tried your first option with mercurialrecipe, I 
had to run bin/buildout twice to make it work as I expected:

1/ First run of bin/buildout: will use `pyrtm' egg from PyPI and will 
for the first time, do a checkout of `pyrtm' from bitbucket to 
pyrtm-repository

2/ Second run of bin/buildout: will use the local `pyrtm' checkout.

So one must remember to run bin/buildout twice, which is less than ideal 
.. especially if someone forgets to do so, thus ending up with the PyPI 
egg of pyrtm.

-srid

From sridharr at activestate.com  Fri Jan 29 02:54:37 2010
From: sridharr at activestate.com (Sridhar Ratnakumar)
Date: Thu, 28 Jan 2010 17:54:37 -0800
Subject: [Distutils] Buildout: Including another Python project
	via	mercurial?
In-Reply-To: <4B623E47.7020800@activestate.com>
References: <4B61E651.3020600@activestate.com>	<20100128225719.0d9da9cb@gourami>
	<4B623E47.7020800@activestate.com>
Message-ID: <4B623FDD.3080009@activestate.com>

On 1/28/2010 5:47 PM, Sridhar Ratnakumar wrote:
>
>> * Use mr.developer [1] to automate this. I didn't find it very useful,
>> though,
>>    but this is closer to what you like to do using mercurialrecipe,
>> despite
>>    mr.developer looks more active and I know several developers which
>> are using
>>    it. It also has a comprehensive documentation, which
>> mercurialrecipe doesn't
>>    have!
>
> This too works. mr.developer 1.9 is buggy and I had to pin version 1.7.

It seems that I will end up choosing mr.developer. For those interested, 
here's the relevant part of my buildout.cfg that successfully uses 
mr.developer to develop an external package in hg repository:

   [buildout]
   develop = .
   parts = python scripts
   versions = versions
   extensions = mr.developer
   sources = sources
   auto-checkout = foo

   [sources]
   foo = hg https://example.com/hg/foo parts/

   [versions]
   mr.developer = 1.7 # 1.9 is buggy (issue 11)

For this to work, you have to ensure that site-packages/ does not 
already contain `foo' .. unless Jim merges Gary's branch and makes a new 
release of buildout: https://bugs.launchpad.net/zc.buildout/+bug/429383

-srid

From barry at python.org  Fri Jan 29 22:05:21 2010
From: barry at python.org (Barry Warsaw)
Date: Fri, 29 Jan 2010 16:05:21 -0500
Subject: [Distutils] distribute 0.6.10 and convert_2to3_doctests
In-Reply-To: <319e029f1001260853x4697afdo252e45f5938028a9@mail.gmail.com>
References: <20100106181718.2a506964@freewill>
	<319e029f1001070309kba96eb8ha8031d2dfd285844@mail.gmail.com>
	<F059AED4-FD82-44D6-A128-5D80DE2A335C@python.org>
	<319e029f1001070534j44556099x89d5029aac9d67e9@mail.gmail.com>
	<319e029f1001260853x4697afdo252e45f5938028a9@mail.gmail.com>
Message-ID: <20100129160521.65eebd10@freewill.wooz.org>

On Jan 26, 2010, at 05:53 PM, Lennart Regebro wrote:

>On Thu, Jan 7, 2010 at 14:34, Lennart Regebro <regebro at gmail.com> wrote:
>> The next problem is that the tests seem to be run on the original, and
>> not on the build-copy. And why that is, I don't know, and I have to
>> debug that, which I can't do right now. I'll try tonight or tomorrow.
>> It's most likely a bug in Distribute.
>
>Well, kinda. :)
>
>The problem is this code in setup.py:
>
>    from munepy import __version__
>
>That means munepy is already imported, so when it then looks for the
>tests to run, it will import it from the already imported munepy

Ah.  We've run into similar problems in other contexts.  On the face of it, I
think it would be wonderful to be able to set the setup.py version number this
way, but in practice it seems too problematic.  I think this ends up biting
namespace packages fairly hard too.

>module. Changing it to
>
>    from munepy import __version__
>    del sys.modules['munepy']
>
>Goes around the problem, but it's admittedly not a pretty fix.
>I'm sure others will be bitten by this too. I'm not sure what a good
>fix would be, except possibly removing all modules specified in
>setup.py from sys.modules before running any commands.

I'm going to make the following change to setup.py instead:

=== modified file 'setup.py'
--- setup.py	2010-01-08 21:59:23 +0000
+++ setup.py	2010-01-29 20:55:12 +0000
@@ -18,9 +18,22 @@
 import distribute_setup
 distribute_setup.use_setuptools()
 
+import re
 import sys
 
-from munepy import __version__
+# Do not import __version__ from munepy.  Doing so causes problems with
+# doctests running under 2to3.
+with open('munepy/__init__.py') as fp:
+    for line in fp:
+        if line.startswith('__version__'):
+            mo = re.search(r'\d+.\d+.\d', line)
+            assert mo, 'No valid __version__ string found'
+            __version__ = mo.group(0)
+            break
+    else:
+        raise AssertionError('No __version__ assignment found')
+
+
 from setuptools import setup, find_packages
 

However, it would be nice if setuptools/distribute supported something like
this out of the box.  The important thing is to have exactly one place to set
the package's version number.

I've had to make a few other changes to the code to get it to pass under 2to3,
but I don't think those are on topic for this mailing list, so I'll skip them.

Thanks for looking into this!
-Barry

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20100129/6f30f9e2/attachment.pgp>

From ziade.tarek at gmail.com  Fri Jan 29 22:27:57 2010
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Fri, 29 Jan 2010 22:27:57 +0100
Subject: [Distutils] distribute 0.6.10 and convert_2to3_doctests
In-Reply-To: <20100129160521.65eebd10@freewill.wooz.org>
References: <20100106181718.2a506964@freewill>
	<319e029f1001070309kba96eb8ha8031d2dfd285844@mail.gmail.com>
	<F059AED4-FD82-44D6-A128-5D80DE2A335C@python.org>
	<319e029f1001070534j44556099x89d5029aac9d67e9@mail.gmail.com>
	<319e029f1001260853x4697afdo252e45f5938028a9@mail.gmail.com>
	<20100129160521.65eebd10@freewill.wooz.org>
Message-ID: <94bdd2611001291327m7acccf87j91ee5a43da3c42f9@mail.gmail.com>

On Fri, Jan 29, 2010 at 10:05 PM, Barry Warsaw <barry at python.org> wrote:
[..]
> However, it would be nice if setuptools/distribute supported something like
> this out of the box. ?The important thing is to have exactly one place to set
> the package's version number.

For metadata fields like "version", one option I am working on in
Distutils itself is to have a complementary section in the static
setup.cfg file, where you can set some fields:

  [setup]
  name=foo
  version=1.9.8

Once setup() is run, the Distribution class will look at this file, to
complete the options provided by code;

Of course this supposes that the version is not calculated by some
code (like in your solution). But I think a plain, non-development
version, can be static.

Tarek

From regebro at gmail.com  Fri Jan 29 22:29:30 2010
From: regebro at gmail.com (Lennart Regebro)
Date: Fri, 29 Jan 2010 22:29:30 +0100
Subject: [Distutils] distribute 0.6.10 and convert_2to3_doctests
In-Reply-To: <94bdd2611001291327m7acccf87j91ee5a43da3c42f9@mail.gmail.com>
References: <20100106181718.2a506964@freewill>
	<319e029f1001070309kba96eb8ha8031d2dfd285844@mail.gmail.com>
	<F059AED4-FD82-44D6-A128-5D80DE2A335C@python.org>
	<319e029f1001070534j44556099x89d5029aac9d67e9@mail.gmail.com>
	<319e029f1001260853x4697afdo252e45f5938028a9@mail.gmail.com>
	<20100129160521.65eebd10@freewill.wooz.org>
	<94bdd2611001291327m7acccf87j91ee5a43da3c42f9@mail.gmail.com>
Message-ID: <319e029f1001291329x3c6550br27be328304560b56@mail.gmail.com>

On Fri, Jan 29, 2010 at 22:27, Tarek Ziad? <ziade.tarek at gmail.com> wrote:
> On Fri, Jan 29, 2010 at 10:05 PM, Barry Warsaw <barry at python.org> wrote:
> [..]
>> However, it would be nice if setuptools/distribute supported something like
>> this out of the box. ?The important thing is to have exactly one place to set
>> the package's version number.
>
> For metadata fields like "version", one option I am working on in
> Distutils itself is to have a complementary section in the static
> setup.cfg file, where you can set some fields:
>
> ?[setup]
> ?name=foo
> ?version=1.9.8
>
> Once setup() is run, the Distribution class will look at this file, to
> complete the options provided by code;
>
> Of course this supposes that the version is not calculated by some
> code (like in your solution). But I think a plain, non-development
> version, can be static.

What you want is then a simple way of getting this version number into
the python code. Any recommendations for that?
-- 
Lennart Regebro: Python, Zope, Plone, Grok
http://regebro.wordpress.com/
+33 661 58 14 64

From tom at recursivedream.com  Fri Jan 29 22:41:30 2010
From: tom at recursivedream.com (Tom Davis)
Date: Fri, 29 Jan 2010 16:41:30 -0500
Subject: [Distutils] distribute doesn't use pip?
Message-ID: <4B63560A.2070204@recursivedream.com>

First, allow me to apologize in advance if this isn't the right place 
for this question. I found this mailing list from the distribute docs, 
but I'm not sure that it's a general support mailing list.

I've read through the distribute docs and either something isn't working 
correctly or my understanding is off. I created a virtualenv using the 
--distribute flag and annotated my setup.py file with the call to 
use_setuptools(). I passed the install_requires argument to setup(), 
including the impossible-to-install-via-easy_install package numpy. My 
understanding was that distribute uses pip instead of the stock 
easy_install, but this does not appear to be the case because "python 
setup.py install" still fails to install numpy, dying with the same 
exception that easy_install always throws. I tried a simple "pip install 
numpy" and it worked, as expected.

Am I missing something? Was distribute never meant to use pip over 
easy_install? Is there someway to flag a package as " 
--single-version-externally-managed"? Am I pretty much doomed in the 
case of wanting to handle the numpy dependency via setup.py?

Thanks!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20100129/6ca65c35/attachment.htm>

From regebro at gmail.com  Fri Jan 29 22:52:43 2010
From: regebro at gmail.com (Lennart Regebro)
Date: Fri, 29 Jan 2010 22:52:43 +0100
Subject: [Distutils] distribute doesn't use pip?
In-Reply-To: <4B63560A.2070204@recursivedream.com>
References: <4B63560A.2070204@recursivedream.com>
Message-ID: <319e029f1001291352k374d65b7lcc72cfe0568e8efa@mail.gmail.com>

On Fri, Jan 29, 2010 at 22:41, Tom Davis <tom at recursivedream.com> wrote:
> Am I missing something? Was distribute never meant to use pip over
> easy_install?

Yes, but not in 0.6. And you could always install pip as well.
Although nowadays you don't have to, because Distribute installs both.

> Am I pretty much doomed in the case of
> wanting to handle the numpy dependency via setup.py?

That's neither easy_install, nor pip, it's Distribute/setuptools that
handles that. It basically runs python setup.py install on the
dependencies. I'm not sure why it wouldn't be able to have numpy as a
dependency,

What exactly is the errors you get?

-- 
Lennart Regebro: Python, Zope, Plone, Grok
http://regebro.wordpress.com/
+33 661 58 14 64

From barry at python.org  Fri Jan 29 22:54:26 2010
From: barry at python.org (Barry Warsaw)
Date: Fri, 29 Jan 2010 16:54:26 -0500
Subject: [Distutils] distribute 0.6.10 and convert_2to3_doctests
In-Reply-To: <94bdd2611001291327m7acccf87j91ee5a43da3c42f9@mail.gmail.com>
References: <20100106181718.2a506964@freewill>
	<319e029f1001070309kba96eb8ha8031d2dfd285844@mail.gmail.com>
	<F059AED4-FD82-44D6-A128-5D80DE2A335C@python.org>
	<319e029f1001070534j44556099x89d5029aac9d67e9@mail.gmail.com>
	<319e029f1001260853x4697afdo252e45f5938028a9@mail.gmail.com>
	<20100129160521.65eebd10@freewill.wooz.org>
	<94bdd2611001291327m7acccf87j91ee5a43da3c42f9@mail.gmail.com>
Message-ID: <20100129165426.12de7aba@freewill.wooz.org>

On Jan 29, 2010, at 10:27 PM, Tarek Ziad? wrote:

>For metadata fields like "version", one option I am working on in
>Distutils itself is to have a complementary section in the static
>setup.cfg file, where you can set some fields:
>
>  [setup]
>  name=foo
>  version=1.9.8
>
>Once setup() is run, the Distribution class will look at this file, to
>complete the options provided by code;
>
>Of course this supposes that the version is not calculated by some
>code (like in your solution). But I think a plain, non-development
>version, can be static.

Actually, my version number is a static assignment in __init__.py:

__version__ = '2.0.2'

and I just manually bump that with every release.  I'd be just as happy to
bump it in setup.cfg (maybe more!) as long as there was an API that I could
add to __init__.py to assign it to my module's namespace, e.g. in
mypkg/__init__.py:

from distribute.resources import get_version
__version__ = get_version('mypkg')

I don't much care how that's spelled.  The important things are:

* One place to bump version numbers
* Available from setup.py without importing from the package
* Available from the package's namespace

-Barry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20100129/056614eb/attachment-0001.pgp>

From ziade.tarek at gmail.com  Fri Jan 29 22:54:44 2010
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Fri, 29 Jan 2010 22:54:44 +0100
Subject: [Distutils] distribute 0.6.10 and convert_2to3_doctests
In-Reply-To: <319e029f1001291329x3c6550br27be328304560b56@mail.gmail.com>
References: <20100106181718.2a506964@freewill>
	<319e029f1001070309kba96eb8ha8031d2dfd285844@mail.gmail.com>
	<F059AED4-FD82-44D6-A128-5D80DE2A335C@python.org>
	<319e029f1001070534j44556099x89d5029aac9d67e9@mail.gmail.com>
	<319e029f1001260853x4697afdo252e45f5938028a9@mail.gmail.com>
	<20100129160521.65eebd10@freewill.wooz.org>
	<94bdd2611001291327m7acccf87j91ee5a43da3c42f9@mail.gmail.com>
	<319e029f1001291329x3c6550br27be328304560b56@mail.gmail.com>
Message-ID: <94bdd2611001291354k42a51d1ci40583e4b669758e@mail.gmail.com>

On Fri, Jan 29, 2010 at 10:29 PM, Lennart Regebro <regebro at gmail.com> wrote:
> On Fri, Jan 29, 2010 at 22:27, Tarek Ziad? <ziade.tarek at gmail.com> wrote:
>> On Fri, Jan 29, 2010 at 10:05 PM, Barry Warsaw <barry at python.org> wrote:
>> [..]
>>> However, it would be nice if setuptools/distribute supported something like
>>> this out of the box. ?The important thing is to have exactly one place to set
>>> the package's version number.
>>
>> For metadata fields like "version", one option I am working on in
>> Distutils itself is to have a complementary section in the static
>> setup.cfg file, where you can set some fields:
>>
>> ?[setup]
>> ?name=foo
>> ?version=1.9.8
>>
>> Once setup() is run, the Distribution class will look at this file, to
>> complete the options provided by code;
>>
>> Of course this supposes that the version is not calculated by some
>> code (like in your solution). But I think a plain, non-development
>> version, can be static.
>
> What you want is then a simple way of getting this version number into
> the python code. Any recommendations for that?

It depends on what code. Let's say that we want to have one and only
one place for the
"version" value.

There are two type of code in a Distutils-based project. The one that
is used in setup.py to create distribution, compile extensions (I'll
call it the "build code"), and the one that is installed on the target
system.

For the build code, if Distutils has the capability to get metadata
from setup.cfg, then it would be just a matter of publishing an API
for getting it as well in there.

Now, if the project is installed, setup.[py/cfg] are gone, and the
only place where the version is located is the PKG-INFO file.
Distribute/Setuptools provides and APIs to read this PKG-INFO file and
get it already. IOW, in the packages and modules of the project, this
API can be used.

The only concern I have is that the development mode (e.g. getting the
version in the packages and modules of the project when it's not
installed) supposes that the "develop" command was called (so that the
PKG-INFO file is locally available).

But I would definitely completely isolate setup.py code from the
project' packages/modules to avoid problems.

Tarek

From regebro at gmail.com  Fri Jan 29 23:00:48 2010
From: regebro at gmail.com (Lennart Regebro)
Date: Fri, 29 Jan 2010 23:00:48 +0100
Subject: [Distutils] distribute doesn't use pip?
In-Reply-To: <319e029f1001291352k374d65b7lcc72cfe0568e8efa@mail.gmail.com>
References: <4B63560A.2070204@recursivedream.com>
	<319e029f1001291352k374d65b7lcc72cfe0568e8efa@mail.gmail.com>
Message-ID: <319e029f1001291400k2daad02emdefa095ba2f02ed8@mail.gmail.com>

On Fri, Jan 29, 2010 at 22:52, Lennart Regebro <regebro at gmail.com> wrote:
> That's neither easy_install, nor pip, it's Distribute/setuptools that
> handles that. It basically runs python setup.py install on the
> dependencies. I'm not sure why it wouldn't be able to have numpy as a
> dependency,

Well, OK, apparently pip looks at the dependencies first and installs
them separately. But if you ask Distribute to install a package it
will try to resolve the package dependencies and install them.
Apparently the subclassed distutils commands numpy uses can't handle
being installed that way.

IMO that's a numpy bug.

-- 
Lennart Regebro: Python, Zope, Plone, Grok
http://regebro.wordpress.com/
+33 661 58 14 64

From ziade.tarek at gmail.com  Fri Jan 29 23:03:39 2010
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Fri, 29 Jan 2010 23:03:39 +0100
Subject: [Distutils] distribute 0.6.10 and convert_2to3_doctests
In-Reply-To: <20100129165426.12de7aba@freewill.wooz.org>
References: <20100106181718.2a506964@freewill>
	<319e029f1001070309kba96eb8ha8031d2dfd285844@mail.gmail.com>
	<F059AED4-FD82-44D6-A128-5D80DE2A335C@python.org>
	<319e029f1001070534j44556099x89d5029aac9d67e9@mail.gmail.com>
	<319e029f1001260853x4697afdo252e45f5938028a9@mail.gmail.com>
	<20100129160521.65eebd10@freewill.wooz.org>
	<94bdd2611001291327m7acccf87j91ee5a43da3c42f9@mail.gmail.com>
	<20100129165426.12de7aba@freewill.wooz.org>
Message-ID: <94bdd2611001291403t370eff57w6c93a8347c739146@mail.gmail.com>

On Fri, Jan 29, 2010 at 10:54 PM, Barry Warsaw <barry at python.org> wrote:
[..]
>
> * One place to bump version numbers
> * Available from setup.py without importing from the package

So yes, setup.cfg would work here.

> * Available from the package's namespace

Yes, that's how Jinja does already for example, using Setuptools's
pkg_resources :

__version__ = __import__('pkg_resources').get_distribution('Jinja2').version

see http://dev.pocoo.org/projects/jinja/browser/jinja2/__init__.py

Notice that this pkg_resources browsing feature would be in Distutils
once PEP 376 is accepted, so until then, I could probably backport in
Distribute the setup.cfg feature.

Tarek

From tom at recursivedream.com  Fri Jan 29 23:03:36 2010
From: tom at recursivedream.com (Tom Davis)
Date: Fri, 29 Jan 2010 17:03:36 -0500
Subject: [Distutils] distribute doesn't use pip?
In-Reply-To: <319e029f1001291352k374d65b7lcc72cfe0568e8efa@mail.gmail.com>
References: <4B63560A.2070204@recursivedream.com>
	<319e029f1001291352k374d65b7lcc72cfe0568e8efa@mail.gmail.com>
Message-ID: <b96b26d21001291403q39ca9d55i4c496d02fff6f8c9@mail.gmail.com>

>
> What exactly is the errors you get?


Here's the traceback; it's rather lengthy:

Traceback (most recent call last):

  File "setup.py", line 12, in <module>

    '
http://downloads.sourceforge.net/project/matplotlib/matplotlib/matplotlib-0.99.1/matplotlib-0.99.1.2.tar.gz
',

  File "/usr/lib/python2.5/distutils/core.py", line 151, in setup

    dist.run_commands()

  File "/usr/lib/python2.5/distutils/dist.py", line 974, in run_commands

    self.run_command(cmd)

  File "/usr/lib/python2.5/distutils/dist.py", line 994, in run_command

    cmd_obj.run()

  File
"/deploy/store/ENV/lib/python2.5/site-packages/distribute-0.6.10-py2.5.egg/setuptools/command/install.py",
line 73, in run

    self.do_egg_install()

  File
"/deploy/store/ENV/lib/python2.5/site-packages/distribute-0.6.10-py2.5.egg/setuptools/command/install.py",
line 101, in do_egg_install

    cmd.run()

  File
"/deploy/store/ENV/lib/python2.5/site-packages/distribute-0.6.10-py2.5.egg/setuptools/command/easy_install.py",
line 236, in run

    self.easy_install(spec, not self.no_deps)

  File
"/deploy/store/ENV/lib/python2.5/site-packages/distribute-0.6.10-py2.5.egg/setuptools/command/easy_in

stall.py", line 452, in easy_install

    return self.install_item(None, spec, tmpdir, deps, True)

  File
"/deploy/store/ENV/lib/python2.5/site-packages/distribute-0.6.10-py2.5.egg/setuptools/command/easy_install.py",
line 503, in install_item

    self.process_distribution(spec, dist, deps)

  File
"/deploy/store/ENV/lib/python2.5/site-packages/distribute-0.6.10-py2.5.egg/setuptools/command/easy_install.py",
line 544, in process_distribution

    [requirement], self.local_index, self.easy_install

  File
"/deploy/store/ENV/lib/python2.5/site-packages/distribute-0.6.10-py2.5.egg/pkg_resources.py",
line 538, in resolve

    dist = best[req.key] = env.best_match(req, self, installer)

  File
"/deploy/store/ENV/lib/python2.5/site-packages/distribute-0.6.10-py2.5.egg/pkg_resources.py",
line 780, in best_match

    return self.obtain(req, installer) # try and download/install

  File
"/deploy/store/ENV/lib/python2.5/site-packages/distribute-0.6.10-py2.5.egg/pkg_resources.py",
line 792, in obtain

    return installer(requirement)

  File
"/deploy/store/ENV/lib/python2.5/site-packages/distribute-0.6.10-py2.5.egg/setuptools/command/easy_install.py",
line 471, in easy_install

    return self.install_item(spec, dist.location, tmpdir, deps)

  File
"/deploy/store/ENV/lib/python2.5/site-packages/distribute-0.6.10-py2.5.egg/setuptools/command/easy_install.py",
line 501, in install_item

    dists = self.install_eggs(spec, download, tmpdir)

  File
"/deploy/store/ENV/lib/python2.5/site-packages/distribute-0.6.10-py2.5.egg/setuptools/command/easy_install.py",
line 680, in install_eggs

    return self.build_and_install(setup_script, setup_base)

  File
"/deploy/store/ENV/lib/python2.5/site-packages/distribute-0.6.10-py2.5.egg/setuptools/command/easy_install.py",
line 957, in build_and_install

    self.run_setup(setup_script, setup_base, args)

  File
"/deploy/store/ENV/lib/python2.5/site-packages/distribute-0.6.10-py2.5.egg/setuptools/command/easy_install.py",
line 946, in run_setup

    run_setup(setup_script, args)

  File
"/deploy/store/ENV/lib/python2.5/site-packages/distribute-0.6.10-py2.5.egg/setuptools/sandbox.py",
line 29, in run_setup

    lambda: execfile(
  File
"/deploy/store/ENV/lib/python2.5/site-packages/distribute-0.6.10-py2.5.egg/setuptools/sandbox.py",
line 70, in run
    return func()
  File
"/deploy/store/ENV/lib/python2.5/site-packages/distribute-0.6.10-py2.5.egg/setuptools/sandbox.py",
line 31, in <lambda>
    {'__file__':setup_script, '__name__':'__main__'}
  File "setup.py", line 187, in <module>

  File "setup.py", line 180, in setup_package

  File "/tmp/easy_install-m7gqed/numpy-1.4.0/numpy/distutils/core.py", line
152, in setup
  File "setup.py", line 143, in configuration

  File "/tmp/easy_install-m7gqed/numpy-1.4.0/numpy/distutils/misc_util.py",
line 957, in add_subpackage
  File "/tmp/easy_install-m7gqed/numpy-1.4.0/numpy/distutils/misc_util.py",
line 926, in get_subpackage
  File "/tmp/easy_install-m7gqed/numpy-1.4.0/numpy/distutils/misc_util.py",
line 863, in _get_configuration_from_setup_py
  File "/deploy/store/store/setup.py", line 8, in configuration
    packages = find_packages('src', exclude=['distribute_setup.py']),
  File "/tmp/easy_install-m7gqed/numpy-1.4.0/numpy/distutils/misc_util.py",
line 957, in add_subpackage
  File "/tmp/easy_install-m7gqed/numpy-1.4.0/numpy/distutils/misc_util.py",
line 926, in get_subpackage
  File "/tmp/easy_install-m7gqed/numpy-1.4.0/numpy/distutils/misc_util.py",
line 863, in _get_configuration_from_setup_py
  File "/deploy/store/store/setup.py", line 81, in configuration

  File "/tmp/easy_install-m7gqed/numpy-1.4.0/numpy/distutils/misc_util.py",
line 1668, in add_scripts
AttributeError: 'NoneType' object has no attribute 'extend'
zsh: exit 1     python setup.py install


Basically, the numpy folks have said they have no plans to support
easy_install because it uses eggs (
http://projects.scipy.org/numpy/ticket/860) which I understand and they are
right that it works just fine using pip because it's installed from source;
but you're saying the same thing here, AFAIK:

It basically runs python setup.py install on the dependencies


So I guess I'm at a loss as to why it's not working as intended.

On Fri, Jan 29, 2010 at 4:52 PM, Lennart Regebro <regebro at gmail.com> wrote:

> On Fri, Jan 29, 2010 at 22:41, Tom Davis <tom at recursivedream.com> wrote:
> > Am I missing something? Was distribute never meant to use pip over
> > easy_install?
>
> Yes, but not in 0.6. And you could always install pip as well.
> Although nowadays you don't have to, because Distribute installs both.
>
> > Am I pretty much doomed in the case of
> > wanting to handle the numpy dependency via setup.py?
>
> That's neither easy_install, nor pip, it's Distribute/setuptools that
> handles that. It basically runs python setup.py install on the
> dependencies. I'm not sure why it wouldn't be able to have numpy as a
> dependency,
>
> What exactly is the errors you get?
>
> --
> Lennart Regebro: Python, Zope, Plone, Grok
> http://regebro.wordpress.com/
> +33 661 58 14 64
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20100129/5701832a/attachment-0001.htm>

From robert.kern at gmail.com  Fri Jan 29 23:19:37 2010
From: robert.kern at gmail.com (Robert Kern)
Date: Fri, 29 Jan 2010 16:19:37 -0600
Subject: [Distutils] distribute doesn't use pip?
In-Reply-To: <b96b26d21001291403q39ca9d55i4c496d02fff6f8c9@mail.gmail.com>
References: <4B63560A.2070204@recursivedream.com>	<319e029f1001291352k374d65b7lcc72cfe0568e8efa@mail.gmail.com>
	<b96b26d21001291403q39ca9d55i4c496d02fff6f8c9@mail.gmail.com>
Message-ID: <hjvmto$p8v$1@ger.gmane.org>

On 2010-01-29 16:03 PM, Tom Davis wrote:

>        File
>     "/tmp/easy_install-m7gqed/numpy-1.4.0/numpy/distutils/misc_util.py",
>     line 1668, in add_scripts
>     AttributeError: 'NoneType' object has no attribute 'extend'

I think I may have fixed it in numpy r8080.

-- 
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
  that is made terrible by our own mad attempt to interpret it as though it had
  an underlying truth."
   -- Umberto Eco


From tom at recursivedream.com  Fri Jan 29 23:46:11 2010
From: tom at recursivedream.com (Tom Davis)
Date: Fri, 29 Jan 2010 17:46:11 -0500
Subject: [Distutils] distribute doesn't use pip?
In-Reply-To: <hjvmto$p8v$1@ger.gmane.org>
References: <4B63560A.2070204@recursivedream.com>
	<319e029f1001291352k374d65b7lcc72cfe0568e8efa@mail.gmail.com> 
	<b96b26d21001291403q39ca9d55i4c496d02fff6f8c9@mail.gmail.com> 
	<hjvmto$p8v$1@ger.gmane.org>
Message-ID: <b96b26d21001291446h62beb628nc6bee8dd448423a9@mail.gmail.com>

I downloaded a snapshot, added it to dependency_links, and ran *setup.py
install* again. It threw the same exception.

On Fri, Jan 29, 2010 at 5:19 PM, Robert Kern <robert.kern at gmail.com> wrote:

> On 2010-01-29 16:03 PM, Tom Davis wrote:
>
>        File
>>    "/tmp/easy_install-m7gqed/numpy-1.4.0/numpy/distutils/misc_util.py",
>>    line 1668, in add_scripts
>>    AttributeError: 'NoneType' object has no attribute 'extend'
>>
>
> I think I may have fixed it in numpy r8080.
>
> --
> Robert Kern
>
> "I have come to believe that the whole world is an enigma, a harmless
> enigma
>  that is made terrible by our own mad attempt to interpret it as though it
> had
>  an underlying truth."
>  -- Umberto Eco
>
> _______________________________________________
> Distutils-SIG maillist  -  Distutils-SIG at python.org
> http://mail.python.org/mailman/listinfo/distutils-sig
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20100129/d98da944/attachment.htm>

From tom at recursivedream.com  Fri Jan 29 23:47:48 2010
From: tom at recursivedream.com (Tom Davis)
Date: Fri, 29 Jan 2010 17:47:48 -0500
Subject: [Distutils] distribute doesn't use pip?
In-Reply-To: <b96b26d21001291446h62beb628nc6bee8dd448423a9@mail.gmail.com>
References: <4B63560A.2070204@recursivedream.com>
	<319e029f1001291352k374d65b7lcc72cfe0568e8efa@mail.gmail.com> 
	<b96b26d21001291403q39ca9d55i4c496d02fff6f8c9@mail.gmail.com> 
	<hjvmto$p8v$1@ger.gmane.org>
	<b96b26d21001291446h62beb628nc6bee8dd448423a9@mail.gmail.com>
Message-ID: <b96b26d21001291447u3e23839al15dd862992c363d7@mail.gmail.com>

Oops, my apologies! The new error location is:

File "/tmp/easy_install-JJUS9R/numpy/numpy/distutils/misc_util.py", line
1278, in add_include_dirs
AttributeError: 'NoneType' object has no attribute 'extend'


On Fri, Jan 29, 2010 at 5:46 PM, Tom Davis <tom at recursivedream.com> wrote:

> I downloaded a snapshot, added it to dependency_links, and ran *setup.py
> install* again. It threw the same exception.
>
>
> On Fri, Jan 29, 2010 at 5:19 PM, Robert Kern <robert.kern at gmail.com>wrote:
>
>> On 2010-01-29 16:03 PM, Tom Davis wrote:
>>
>>        File
>>>    "/tmp/easy_install-m7gqed/numpy-1.4.0/numpy/distutils/misc_util.py",
>>>    line 1668, in add_scripts
>>>    AttributeError: 'NoneType' object has no attribute 'extend'
>>>
>>
>> I think I may have fixed it in numpy r8080.
>>
>> --
>> Robert Kern
>>
>> "I have come to believe that the whole world is an enigma, a harmless
>> enigma
>>  that is made terrible by our own mad attempt to interpret it as though it
>> had
>>  an underlying truth."
>>  -- Umberto Eco
>>
>> _______________________________________________
>> Distutils-SIG maillist  -  Distutils-SIG at python.org
>> http://mail.python.org/mailman/listinfo/distutils-sig
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20100129/c974c080/attachment.htm>

From robert.kern at gmail.com  Fri Jan 29 23:48:36 2010
From: robert.kern at gmail.com (Robert Kern)
Date: Fri, 29 Jan 2010 16:48:36 -0600
Subject: [Distutils] distribute doesn't use pip?
In-Reply-To: <b96b26d21001291446h62beb628nc6bee8dd448423a9@mail.gmail.com>
References: <4B63560A.2070204@recursivedream.com>	<319e029f1001291352k374d65b7lcc72cfe0568e8efa@mail.gmail.com>
	<b96b26d21001291403q39ca9d55i4c496d02fff6f8c9@mail.gmail.com>
	<hjvmto$p8v$1@ger.gmane.org>
	<b96b26d21001291446h62beb628nc6bee8dd448423a9@mail.gmail.com>
Message-ID: <hjvok3$v26$1@ger.gmane.org>

On 2010-01-29 16:46 PM, Tom Davis wrote:
> I downloaded a snapshot, added it to dependency_links, and ran /setup.py
> install/ again. It threw the same exception.

Traceback, please?

-- 
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
  that is made terrible by our own mad attempt to interpret it as though it had
  an underlying truth."
   -- Umberto Eco


From robert.kern at gmail.com  Fri Jan 29 23:51:42 2010
From: robert.kern at gmail.com (Robert Kern)
Date: Fri, 29 Jan 2010 16:51:42 -0600
Subject: [Distutils] distribute doesn't use pip?
In-Reply-To: <b96b26d21001291447u3e23839al15dd862992c363d7@mail.gmail.com>
References: <4B63560A.2070204@recursivedream.com>	<319e029f1001291352k374d65b7lcc72cfe0568e8efa@mail.gmail.com>
	<b96b26d21001291403q39ca9d55i4c496d02fff6f8c9@mail.gmail.com>
	<hjvmto$p8v$1@ger.gmane.org>	<b96b26d21001291446h62beb628nc6bee8dd448423a9@mail.gmail.com>
	<b96b26d21001291447u3e23839al15dd862992c363d7@mail.gmail.com>
Message-ID: <hjvopt$v26$2@ger.gmane.org>

On 2010-01-29 16:47 PM, Tom Davis wrote:
> Oops, my apologies! The new error location is:
>
>     File "/tmp/easy_install-JJUS9R/numpy/numpy/distutils/misc_util.py",
>     line 1278, in add_include_dirs
>     AttributeError: 'NoneType' object has no attribute 'extend'

Thank you for the traceback! Try r8081. I fixed a couple of other places where 
lists may not be initialized properly.

-- 
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
  that is made terrible by our own mad attempt to interpret it as though it had
  an underlying truth."
   -- Umberto Eco


From tom at recursivedream.com  Sat Jan 30 00:08:23 2010
From: tom at recursivedream.com (Tom Davis)
Date: Fri, 29 Jan 2010 18:08:23 -0500
Subject: [Distutils] distribute doesn't use pip?
In-Reply-To: <hjvopt$v26$2@ger.gmane.org>
References: <4B63560A.2070204@recursivedream.com>
	<319e029f1001291352k374d65b7lcc72cfe0568e8efa@mail.gmail.com> 
	<b96b26d21001291403q39ca9d55i4c496d02fff6f8c9@mail.gmail.com> 
	<hjvmto$p8v$1@ger.gmane.org>
	<b96b26d21001291446h62beb628nc6bee8dd448423a9@mail.gmail.com> 
	<b96b26d21001291447u3e23839al15dd862992c363d7@mail.gmail.com> 
	<hjvopt$v26$2@ger.gmane.org>
Message-ID: <b96b26d21001291508m7a0b980o92797d4a5c00e56e@mail.gmail.com>

Tested; failed with the following:

  File "setup.py", line 203, in setup_package

  File "/tmp/easy_install-cmuJYo/numpy/numpy/distutils/core.py", line 186,
in setup
  File "/usr/lib/python2.5/distutils/core.py", line 151, in setup
    dist.run_commands()
  File "/usr/lib/python2.5/distutils/dist.py", line 974, in run_commands
    self.run_command(cmd)
  File "/usr/lib/python2.5/distutils/dist.py", line 994, in run_command
    cmd_obj.run()
  File
"/deploy/ENV/lib/python2.5/site-packages/distribute-0.6.10-py2.5.egg/setuptools/command/bdist_egg.py",
line 167, in run
    self.run_command("egg_info")
  File "/usr/lib/python2.5/distutils/cmd.py", line 333, in run_command
    self.distribution.run_command(command)
  File "/usr/lib/python2.5/distutils/dist.py", line 994, in run_command
    cmd_obj.run()
  File "/tmp/easy_install-cmuJYo/numpy/numpy/distutils/command/egg_info.py",
line 8, in run
  File "/usr/lib/python2.5/distutils/cmd.py", line 333, in run_command
    self.distribution.run_command(command)
  File "/usr/lib/python2.5/distutils/dist.py", line 994, in run_command
    cmd_obj.run()
  File
"/tmp/easy_install-cmuJYo/numpy/numpy/distutils/command/build_src.py", line
152, in run
  File
"/tmp/easy_install-cmuJYo/numpy/numpy/distutils/command/build_src.py", line
169, in build_sources
  File
"/tmp/easy_install-cmuJYo/numpy/numpy/distutils/command/build_src.py", line
328, in build_extension_sources
  File
"/tmp/easy_install-cmuJYo/numpy/numpy/distutils/command/build_src.py", line
385, in generate_sources
  File "/deploy/repo/setup.py", line 390, in generate_config_h

  File "/deploy/repo/setup.py", line 41, in check_types

  File "/deploy/repo/setup.py", line 255, in check_types

SystemError: Cannot compiler 'Python.h'. Perhaps you need to install
python-dev|python-devel.
Error in atexit._run_exitfuncs:
Traceback (most recent call last):
  File "/usr/lib/python2.5/atexit.py", line 24, in _run_exitfuncs
    func(*targs, **kargs)
  File "/tmp/easy_install-cmuJYo/numpy/numpy/distutils/misc_util.py", line
250, in clean_up_temporary_directory
SystemError: Parent module 'numpy.distutils' not loaded
Error in sys.exitfunc:
Traceback (most recent call last):
  File "/usr/lib/python2.5/atexit.py", line 24, in _run_exitfuncs
    func(*targs, **kargs)
  File "/tmp/easy_install-cmuJYo/numpy/numpy/distutils/misc_util.py", line
250, in clean_up_temporary_directory
SystemError: Parent module 'numpy.distutils' not loaded
zsh: exit 1     python setup.py install


I'm not sure if the former is an issue with numpy or something else (issue
with Python.h). Although i am positive my dev headers are installed (and
numpy still installs fine with pip), I don't know if distutils is having
trouble finding them for some unrelated-to-numpy reason. I can't think of
another package offhand that requires the headers or I'd test that theory.

On Fri, Jan 29, 2010 at 5:51 PM, Robert Kern <robert.kern at gmail.com> wrote:

> On 2010-01-29 16:47 PM, Tom Davis wrote:
>
>> Oops, my apologies! The new error location is:
>>
>>    File "/tmp/easy_install-JJUS9R/numpy/numpy/distutils/misc_util.py",
>>    line 1278, in add_include_dirs
>>    AttributeError: 'NoneType' object has no attribute 'extend'
>>
>
> Thank you for the traceback! Try r8081. I fixed a couple of other places
> where lists may not be initialized properly.
>
>
> --
> Robert Kern
>
> "I have come to believe that the whole world is an enigma, a harmless
> enigma
>  that is made terrible by our own mad attempt to interpret it as though it
> had
>  an underlying truth."
>  -- Umberto Eco
>
> _______________________________________________
> Distutils-SIG maillist  -  Distutils-SIG at python.org
> http://mail.python.org/mailman/listinfo/distutils-sig
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20100129/ff68fb98/attachment-0001.htm>

From robert.kern at gmail.com  Sat Jan 30 00:27:37 2010
From: robert.kern at gmail.com (Robert Kern)
Date: Fri, 29 Jan 2010 17:27:37 -0600
Subject: [Distutils] distribute doesn't use pip?
In-Reply-To: <b96b26d21001291508m7a0b980o92797d4a5c00e56e@mail.gmail.com>
References: <4B63560A.2070204@recursivedream.com>	<319e029f1001291352k374d65b7lcc72cfe0568e8efa@mail.gmail.com>
	<b96b26d21001291403q39ca9d55i4c496d02fff6f8c9@mail.gmail.com>
	<hjvmto$p8v$1@ger.gmane.org>	<b96b26d21001291446h62beb628nc6bee8dd448423a9@mail.gmail.com>
	<b96b26d21001291447u3e23839al15dd862992c363d7@mail.gmail.com>
	<hjvopt$v26$2@ger.gmane.org>
	<b96b26d21001291508m7a0b980o92797d4a5c00e56e@mail.gmail.com>
Message-ID: <hjvqt8$66n$1@ger.gmane.org>

On 2010-01-29 17:08 PM, Tom Davis wrote:
> Tested; failed with the following:
>
>        File
>     "/tmp/easy_install-cmuJYo/numpy/numpy/distutils/command/build_src.py",
>     line 385, in generate_sources
>        File "/deploy/repo/setup.py", line 390, in generate_config_h
>        File "/deploy/repo/setup.py", line 41, in check_types
>        File "/deploy/repo/setup.py", line 255, in check_types
>     SystemError: Cannot compiler 'Python.h'. Perhaps you need to install
>     python-dev|python-devel.

> I'm not sure if the former is an issue with numpy or something else
> (issue with Python.h). Although i am positive my dev headers are
> installed (and numpy still installs fine with pip), I don't know if
> distutils is having trouble finding them for some unrelated-to-numpy
> reason. I can't think of another package offhand that requires the
> headers or I'd test that theory.

Try this patch to see some more output about the failed compile. It will be the 
second piece of code dumped. You should see something like the following:


Generating build/src.macosx-10.3-i386-2.5/numpy/core/include/numpy/config.h
compiling '_configtest.c':
#include <Python.h>

/* we need a dummy line to make distutils happy */
C compiler: gcc -arch ppc -arch i386 -isysroot /Developer/SDKs/MacOSX10.4u.sdk 
-fno-strict-aliasing -Wno-long-double -no-cpp-precomp -mno-fused-madd 
-fno-common -dynamic -DNDEBUG -g -O3

compile options: '-Inumpy/core/src/private -Inumpy/core/src -Inumpy/core 
-Inumpy/core/src/npymath -Inumpy/core/src/multiarray -Inumpy/core/src/umath 
-Inumpy/core/include 
-I/Library/Frameworks/Python.framework/Versions/2.5/include/python2.5 -c'
gcc: _configtest.c
success!


Please verify that Python.h exists in one of the -I locations. It is possible 
that we are passing something weird.


Index: numpy/distutils/misc_util.py
===================================================================
--- numpy/distutils/misc_util.py        (revision 8081)
+++ numpy/distutils/misc_util.py        (working copy)
@@ -1733,8 +1733,8 @@
          """
          cmd = get_cmd('config')
          cmd.ensure_finalized()
-        cmd.dump_source = 0
-        cmd.noisy = 0
+        cmd.dump_source = 1
+        cmd.noisy = 1
          old_path = os.environ.get('PATH')
          if old_path:
              path = os.pathsep.join(['.',old_path])

You may want to join us over numpy-discussion until we identify real issues with 
Distribute or pip.

-- 
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
  that is made terrible by our own mad attempt to interpret it as though it had
  an underlying truth."
   -- Umberto Eco


From pje at telecommunity.com  Sat Jan 30 00:53:08 2010
From: pje at telecommunity.com (P.J. Eby)
Date: Fri, 29 Jan 2010 18:53:08 -0500
Subject: [Distutils] distribute 0.6.10 and convert_2to3_doctests
In-Reply-To: <20100129160521.65eebd10@freewill.wooz.org>
References: <20100106181718.2a506964@freewill>
	<319e029f1001070309kba96eb8ha8031d2dfd285844@mail.gmail.com>
	<F059AED4-FD82-44D6-A128-5D80DE2A335C@python.org>
	<319e029f1001070534j44556099x89d5029aac9d67e9@mail.gmail.com>
	<319e029f1001260853x4697afdo252e45f5938028a9@mail.gmail.com>
	<20100129160521.65eebd10@freewill.wooz.org>
Message-ID: <20100129235317.AA8683A4076@sparrow.telecommunity.com>

At 04:05 PM 1/29/2010 -0500, Barry Warsaw wrote:
>The important thing is to have exactly one place to set
>the package's version number.

Put it in setup.py, then.  If you absolutely must have a __version__ 
at runtime, use this to extract it from the installation metadata:

     __version__ = pkg_resources.require('MyProject')[0].version

Mostly, though, I don't bother with having a __version__ in my 
modules or packages any more, since you can just do the above if you 
want to check the installed version of something.


From ben+python at benfinney.id.au  Sat Jan 30 01:32:23 2010
From: ben+python at benfinney.id.au (Ben Finney)
Date: Sat, 30 Jan 2010 11:32:23 +1100
Subject: [Distutils] distribute 0.6.10 and convert_2to3_doctests
References: <20100106181718.2a506964@freewill>
	<319e029f1001070309kba96eb8ha8031d2dfd285844@mail.gmail.com>
	<F059AED4-FD82-44D6-A128-5D80DE2A335C@python.org>
	<319e029f1001070534j44556099x89d5029aac9d67e9@mail.gmail.com>
	<319e029f1001260853x4697afdo252e45f5938028a9@mail.gmail.com>
	<20100129160521.65eebd10@freewill.wooz.org>
	<20100129235317.AA8683A4076@sparrow.telecommunity.com>
Message-ID: <87d40sv3e0.fsf@benfinney.id.au>

"P.J. Eby" <pje at telecommunity.com> writes:

> At 04:05 PM 1/29/2010 -0500, Barry Warsaw wrote:
> >The important thing is to have exactly one place to set the package's
> >version number.
>
> Put it in setup.py, then.  If you absolutely must have a __version__
> at runtime, use this to extract it from the installation metadata:
>
>     __version__ = pkg_resources.require('MyProject')[0].version
>
> Mostly, though, I don't bother with having a __version__ in my modules
> or packages any more, since you can just do the above if you want to
> check the installed version of something.

That assumes that the only things that will need to query the package's
version are Python modules. That's often not the case, especially when
there are other tools (e.g. shell programs, make files, or any program
not written in Python) that are part of the same package.

Better would be to have a *non-executable* data file containing the
version string and other such package meta-data. ?Query the metadata?
should not necessarily imply ?parse or execute a bunch of Python code?.

-- 
 \        ?None can love freedom heartily, but good men; the rest love |
  `\                           not freedom, but license.? ?John Milton |
_o__)                                                                  |
Ben Finney


From ssteinerx at gmail.com  Sat Jan 30 01:50:01 2010
From: ssteinerx at gmail.com (ssteinerX@gmail.com)
Date: Fri, 29 Jan 2010 19:50:01 -0500
Subject: [Distutils] distribute 0.6.10 and convert_2to3_doctests
In-Reply-To: <87d40sv3e0.fsf@benfinney.id.au>
References: <20100106181718.2a506964@freewill>
	<319e029f1001070309kba96eb8ha8031d2dfd285844@mail.gmail.com>
	<F059AED4-FD82-44D6-A128-5D80DE2A335C@python.org>
	<319e029f1001070534j44556099x89d5029aac9d67e9@mail.gmail.com>
	<319e029f1001260853x4697afdo252e45f5938028a9@mail.gmail.com>
	<20100129160521.65eebd10@freewill.wooz.org>
	<20100129235317.AA8683A4076@sparrow.telecommunity.com>
	<87d40sv3e0.fsf@benfinney.id.au>
Message-ID: <8A33D5A8-FD47-4FA6-AA76-0CC34A246F1B@gmail.com>


On Jan 29, 2010, at 7:32 PM, Ben Finney wrote:

> "P.J. Eby" <pje at telecommunity.com> writes:
> 
>> At 04:05 PM 1/29/2010 -0500, Barry Warsaw wrote:
>>> The important thing is to have exactly one place to set the package's
>>> version number.
>> 
>> Put it in setup.py, then.  If you absolutely must have a __version__
>> at runtime, use this to extract it from the installation metadata:
>> 
>>    __version__ = pkg_resources.require('MyProject')[0].version
>> 
>> Mostly, though, I don't bother with having a __version__ in my modules
>> or packages any more, since you can just do the above if you want to
>> check the installed version of something.
> 
> That assumes that the only things that will need to query the package's
> version are Python modules. That's often not the case, especially when
> there are other tools (e.g. shell programs, make files, or any program
> not written in Python) that are part of the same package.
> 
> Better would be to have a *non-executable* data file containing the
> version string and other such package meta-data. ?Query the metadata?
> should not necessarily imply ?parse or execute a bunch of Python code?.

I'd love to have a standard, documented way to set/query module versions.  

I actually started this e-mail about a week ago when I went looking for a "standard" way to version something the other day and, after I couldn't find a definitive answer by Googling, went looking in the stdlib for guidance.

I started with two core modules, sys and distutils, and tried just doing the same things to both modules:

>>> import sys

>>> sys.version
'2.6.4 (r264:75821M, Oct 27 2009, 19:48:32) \n[GCC 4.0.1 (Apple Inc. build 5493)]'

>>> sys.version_info
(2, 6, 4, 'final', 0)

>>> sys.__version__
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: 'module' object has no attribute '__version__'

#--------------------------------------------

>>> import distutils

>>> distutils.version
<module 'distutils.version' from '/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/distutils/version.pyc'>

>>> distutils.version_info
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: 'module' object has no attribute 'version_info'

>>> distutils.__version__
'2.6.4'

The standard library, and modules in PyPI, are all over the place on it so maybe a completely new API/method is in order.

S


From pje at telecommunity.com  Sat Jan 30 01:59:57 2010
From: pje at telecommunity.com (P.J. Eby)
Date: Fri, 29 Jan 2010 19:59:57 -0500
Subject: [Distutils] distribute 0.6.10 and convert_2to3_doctests
In-Reply-To: <87d40sv3e0.fsf@benfinney.id.au>
References: <20100106181718.2a506964@freewill>
	<319e029f1001070309kba96eb8ha8031d2dfd285844@mail.gmail.com>
	<F059AED4-FD82-44D6-A128-5D80DE2A335C@python.org>
	<319e029f1001070534j44556099x89d5029aac9d67e9@mail.gmail.com>
	<319e029f1001260853x4697afdo252e45f5938028a9@mail.gmail.com>
	<20100129160521.65eebd10@freewill.wooz.org>
	<20100129235317.AA8683A4076@sparrow.telecommunity.com>
	<87d40sv3e0.fsf@benfinney.id.au>
Message-ID: <20100130010007.4D2993A4076@sparrow.telecommunity.com>

At 11:32 AM 1/30/2010 +1100, Ben Finney wrote:
>That assumes that the only things that will need to query the 
>package's version are Python modules. That's often not the case, 
>especially when there are other tools (e.g. shell programs, make 
>files, or any program not written in Python) that are part of the 
>same package. Better would be to have a *non-executable* data file 
>containing the version string and other such package meta-data. 
>???Query the metadata??? should not necessarily imply ???parse or 
>execute a bunch of Python code???.

Which is precisely why that way's better; pkg_resources is just 
parsing the info from a PKG-INFO file -- or more commonly, just 
parsing a file or directory *name*, without even opening a file.  So 
other tools can certainly do the same.


From regebro at gmail.com  Sat Jan 30 02:29:11 2010
From: regebro at gmail.com (Lennart Regebro)
Date: Sat, 30 Jan 2010 02:29:11 +0100
Subject: [Distutils] distribute doesn't use pip?
In-Reply-To: <b96b26d21001291403q39ca9d55i4c496d02fff6f8c9@mail.gmail.com>
References: <4B63560A.2070204@recursivedream.com>
	<319e029f1001291352k374d65b7lcc72cfe0568e8efa@mail.gmail.com>
	<b96b26d21001291403q39ca9d55i4c496d02fff6f8c9@mail.gmail.com>
Message-ID: <319e029f1001291729y66e606c9m7555c18b1197306e@mail.gmail.com>

On Fri, Jan 29, 2010 at 23:03, Tom Davis <tom at recursivedream.com> wrote:
> Basically, the numpy folks have said they have no plans to support
> easy_install because it uses eggs

Yeah, that statement is somewhat nonsensical IMO.

>> It basically runs python setup.py install on the?dependencies
>
> So I guess I'm at a loss as to why it's not working as intended.

Me too, but the error is somewhere in their subclassing of distutils,
so there is some sort of interaction between their classes and
setuptools. It's hard to debug if you don't know why numpy does all
these extra thingies in it's setup, and I don't.

-- 
Lennart Regebro: Python, Zope, Plone, Grok
http://regebro.wordpress.com/
+33 661 58 14 64

From cournape at gmail.com  Sat Jan 30 02:58:32 2010
From: cournape at gmail.com (David Cournapeau)
Date: Sat, 30 Jan 2010 10:58:32 +0900
Subject: [Distutils] distribute doesn't use pip?
In-Reply-To: <319e029f1001291729y66e606c9m7555c18b1197306e@mail.gmail.com>
References: <4B63560A.2070204@recursivedream.com>
	<319e029f1001291352k374d65b7lcc72cfe0568e8efa@mail.gmail.com>
	<b96b26d21001291403q39ca9d55i4c496d02fff6f8c9@mail.gmail.com>
	<319e029f1001291729y66e606c9m7555c18b1197306e@mail.gmail.com>
Message-ID: <5b8d13221001291758p137cb786mf5c4303bd585ef4@mail.gmail.com>

On Sat, Jan 30, 2010 at 10:29 AM, Lennart Regebro <regebro at gmail.com> wrote:
> On Fri, Jan 29, 2010 at 23:03, Tom Davis <tom at recursivedream.com> wrote:
>> Basically, the numpy folks have said they have no plans to support
>> easy_install because it uses eggs
>
> Yeah, that statement is somewhat nonsensical IMO.

The problem is not using eggs, but how they are installed by
easy_install/setuptools (flat vs non-flat). As pip install things from
sources, it should not cause the same issues. It seems Robert fixed
some of the issues, and every remaining one will be fixed in due time.

David

From barry at python.org  Sun Jan 31 01:03:58 2010
From: barry at python.org (Barry Warsaw)
Date: Sat, 30 Jan 2010 19:03:58 -0500
Subject: [Distutils] distribute 0.6.10 and convert_2to3_doctests
In-Reply-To: <20100129235317.AA8683A4076@sparrow.telecommunity.com>
References: <20100106181718.2a506964@freewill>
	<319e029f1001070309kba96eb8ha8031d2dfd285844@mail.gmail.com>
	<F059AED4-FD82-44D6-A128-5D80DE2A335C@python.org>
	<319e029f1001070534j44556099x89d5029aac9d67e9@mail.gmail.com>
	<319e029f1001260853x4697afdo252e45f5938028a9@mail.gmail.com>
	<20100129160521.65eebd10@freewill.wooz.org>
	<20100129235317.AA8683A4076@sparrow.telecommunity.com>
Message-ID: <20100130190358.011ad2d7@freewill.wooz.org>

On Jan 29, 2010, at 06:53 PM, P.J. Eby wrote:

>At 04:05 PM 1/29/2010 -0500, Barry Warsaw wrote:
>>The important thing is to have exactly one place to set
>>the package's version number.
>
>Put it in setup.py, then.  If you absolutely must have a __version__ 
>at runtime, use this to extract it from the installation metadata:
>
>     __version__ = pkg_resources.require('MyProject')[0].version
>
>Mostly, though, I don't bother with having a __version__ in my 
>modules or packages any more, since you can just do the above if you 
>want to check the installed version of something.

That's good to know.  What about adding an API to make that even simpler:

pkg_resources.get_version('MyProject')

?

-Barry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20100130/52309d42/attachment.pgp>

From barry at python.org  Sun Jan 31 01:08:57 2010
From: barry at python.org (Barry Warsaw)
Date: Sat, 30 Jan 2010 19:08:57 -0500
Subject: [Distutils] distribute 0.6.10 and convert_2to3_doctests
In-Reply-To: <94bdd2611001291403t370eff57w6c93a8347c739146@mail.gmail.com>
References: <20100106181718.2a506964@freewill>
	<319e029f1001070309kba96eb8ha8031d2dfd285844@mail.gmail.com>
	<F059AED4-FD82-44D6-A128-5D80DE2A335C@python.org>
	<319e029f1001070534j44556099x89d5029aac9d67e9@mail.gmail.com>
	<319e029f1001260853x4697afdo252e45f5938028a9@mail.gmail.com>
	<20100129160521.65eebd10@freewill.wooz.org>
	<94bdd2611001291327m7acccf87j91ee5a43da3c42f9@mail.gmail.com>
	<20100129165426.12de7aba@freewill.wooz.org>
	<94bdd2611001291403t370eff57w6c93a8347c739146@mail.gmail.com>
Message-ID: <20100130190857.015a4382@freewill.wooz.org>

On Jan 29, 2010, at 11:03 PM, Tarek Ziad? wrote:

>Yes, that's how Jinja does already for example, using Setuptools's
>pkg_resources :
>
>__version__ = __import__('pkg_resources').get_distribution('Jinja2').version

And that's different yet again from what PJE suggests.  This is screaming for
a blessed API to be pushed into the stdlib.

(BTW, why use __import__() there?)

>see http://dev.pocoo.org/projects/jinja/browser/jinja2/__init__.py
>
>Notice that this pkg_resources browsing feature would be in Distutils
>once PEP 376 is accepted, so until then, I could probably backport in
>Distribute the setup.cfg feature.

That would be cool.
-Barry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20100130/5ab6e38f/attachment.pgp>

From pje at telecommunity.com  Sun Jan 31 03:51:34 2010
From: pje at telecommunity.com (P.J. Eby)
Date: Sat, 30 Jan 2010 21:51:34 -0500
Subject: [Distutils] distribute 0.6.10 and convert_2to3_doctests
In-Reply-To: <20100130190857.015a4382@freewill.wooz.org>
References: <20100106181718.2a506964@freewill>
	<319e029f1001070309kba96eb8ha8031d2dfd285844@mail.gmail.com>
	<F059AED4-FD82-44D6-A128-5D80DE2A335C@python.org>
	<319e029f1001070534j44556099x89d5029aac9d67e9@mail.gmail.com>
	<319e029f1001260853x4697afdo252e45f5938028a9@mail.gmail.com>
	<20100129160521.65eebd10@freewill.wooz.org>
	<94bdd2611001291327m7acccf87j91ee5a43da3c42f9@mail.gmail.com>
	<20100129165426.12de7aba@freewill.wooz.org>
	<94bdd2611001291403t370eff57w6c93a8347c739146@mail.gmail.com>
	<20100130190857.015a4382@freewill.wooz.org>
Message-ID: <20100131025146.6BF693A4075@sparrow.telecommunity.com>

At 07:08 PM 1/30/2010 -0500, Barry Warsaw wrote:
>On Jan 29, 2010, at 11:03 PM, Tarek Ziad?? wrote:
>
> >Yes, that's how Jinja does already for example, using Setuptools's
> >pkg_resources :
> >
> >__version__ = __import__('pkg_resources').get_distribution('Jinja2').version
>
>And that's different yet again from what PJE suggests.

Not really; just a different way of spelling the same thing.  In 
either case, you're looking at the .version attribute of the 
Distribution instance.


>   This is screaming for
>a blessed API to be pushed into the stdlib.
>
>(BTW, why use __import__() there?)

It lets you save an extra line to import pkg_resources; that's really 
the only difference.


From david.lyon at pythontest.org  Sun Jan 31 07:06:54 2010
From: david.lyon at pythontest.org (David Lyon)
Date: Sun, 31 Jan 2010 17:06:54 +1100 (EST)
Subject: [Distutils] distribute 0.6.10 and convert_2to3_doctests
In-Reply-To: <94bdd2611001291327m7acccf87j91ee5a43da3c42f9@mail.gmail.com>
References: <20100106181718.2a506964@freewill>
	<319e029f1001070309kba96eb8ha8031d2dfd285844@mail.gmail.com>
	<F059AED4-FD82-44D6-A128-5D80DE2A335C@python.org>
	<319e029f1001070534j44556099x89d5029aac9d67e9@mail.gmail.com>
	<319e029f1001260853x4697afdo252e45f5938028a9@mail.gmail.com>
	<20100129160521.65eebd10@freewill.wooz.org>
	<94bdd2611001291327m7acccf87j91ee5a43da3c42f9@mail.gmail.com>
Message-ID: <45982.115.128.31.36.1264918014.squirrel@syd-srv02.ezyreg.com>

Hi Tarek,

> For metadata fields like "version", one option I am working on in
> Distutils itself is to have a complementary section in the static
> setup.cfg file, where you can set some fields:
>
>   [setup]
>   name=foo
>   version=1.9.8

Interesting.

Well it was discussed on the mailing list extensively last
year and I even wrote a PEP proposal that got blocked.. :-)

If I understand correctly, these parameters in the setup.cfg
file would be similar to those passed into the setup() function
to distutils.

I'm asking this question, knowing that the answer is probably
that it was before your time. But it doesn't hurt asking.

Do you have a test suite of parameters for the setup() function
in distutils?

Whichever way I look at this problem I keep coming back to
the issue that unless there is a test suite (TDD style) that
can be used as inputs, there's no viable way to come up
with equivilent functionality through a metadata based system.

To me, there is simply too many combinations of parameters
used in funny ways to obtain the results that the developers
are after.

Does a Parameter testsuite for the setup() function exist
for distutils ? If not, should we be considering building
one? (for distutils)

David



From tmohr at s.netic.de  Sun Jan 31 12:56:20 2010
From: tmohr at s.netic.de (Torsten Mohr)
Date: Sun, 31 Jan 2010 12:56:20 +0100
Subject: [Distutils] setup script for raster-image
Message-ID: <201001311256.20983.tmohr@s.netic.de>

Hello,

please note that i released my first python module in C++, it can be found 
here:

http://sourceforge.net/projects/raster-image/

It would be great if somebody could take a look at the setup script and give 
me some feedback on recommended / necessary changes.


Best regards,
Torsten.