[csw-maintainers] Python 2.7

[Peter FELECAN]

"Maciej (Matchek) Bliziński" <maciej at opencsw.org> writes:

> 2013/7/29 Peter FELECAN <pfelecan at opencsw.org>:
>> "Maciej (Matchek) Bliziński" <maciej at opencsw.org> writes:
>>
>>> 2013/7/29 Peter FELECAN <pfelecan at opencsw.org>:
>>>> the only omission is using a different prefix for 2.6 and 2.7 packages.
>>>>
>>>> Tested it thoroughly and everything seems alright.
>>>>
>>>> Do you mind if I commit these changes? This way we have a necessary and
>>>> sufficient set of changes to support our new toy...
>>>
>>> This line:
>>>
>>> PYTHON_MODULE_PACKAGE_PREFIX_2_7 = CSWpy-
>>>
>>> ...is fine as long as we don't rebuild the CSWpy- packages with Python
>>> 2.7; or more specifically, as long as the packages with the CSWpy-
>>> prefix do provide files in the /opt/csw/lib/python/site-packages or
>>> /opt/csw/lib/python2.6/site-packages directories. This can be easily
>>> encoded into a check in checkpkg. I'm sure you understand the
>>> reasoning ‒ we don't want a regression in 2.6.
>>
>> There are the following cases:
>>
>> 1. The package provides a 2.7 module, i.e., its code use new 2.7
>>    features. In this case it must provide its components in the
>>    versioned trees,
>>    e.g. /opt/csw/lib/python2.7/site-packages. Consequently, no need for
>>    a specific prefix and its dependencies clearly says CSWpython27
>
> One problem with this is the following use case:
>
> A user runs Python 2.6 and thinks "I want the foo module. Does OpenCSW
> provide it?" - runs a quick pkgutil search - "Cool, there's my
> CSWpy-foo in the catalog, let's install it... let's run import foo...
> gah, doesn't work! why is this stuff always broken! opencsw is
> broken!"
>
> Can we prevent the above scenario in any way? For example, provide a
> stub for 2.6 that when you try to import it, it would say: "this
> package is for Python 2.7 only"?

Meh. I don't know. It seems contrived to me.

>> 2. The package provides a "mixed" module, i.e. the code runs on 2.6 and
>>    2.7 interpreter. In this case it should provide a double pronged
>>    installation, i.e., components installed in
>>    /opt/csw/python/site-packages.
>
> Or instead, let's just provide files in
> /opt/csw/python2.6/site-packages and /opt/csw/python2.7/site-packages
> plus their compiled .pyc counterparts, compiled with respective
> interpreters. Simple to do and effective. Why shouldn't we do this?

Indeed. What I thought but not wrote...

>> consequently, no need for a specific
>>    prefix and its dependency specifies CSWpython *and* CSWpython27.
>
> Agreed on the deps. (Also note: if we had CSWpy26- and CSWpy27-, we
> could be more selective.)
>
>> 3. The package provides a 2.6 module (IMHO this is also a 2.7
>>    module).
>
> It surely is, except the 2.6 .pyc files won't work for 2.7.

Are you sure of that? Anyway, the .pyc is rejected and .py is used which
incurs just the extra parsing, isn't it?

>> In this case its components should go in
>>    /opt/csw/lib/python26 and /opt/csw/python27. Consequently there is no
>>    need for a specific prefix.
>
> Agreed.
>
>> 4. Finally, if, as I suggested, the next transition from unstable to a
>>    named catalog defines as an objective to make 2.7 the default
>>    interpreter, there is no need for a specific prefix.
>
> As long as you don't fall into the "let's only support one Python
> version" trap, agreed.

What I propose is eventually to support 2.x and 3.x.

Can I commit the changes?
-- 
Peter