From maciej at opencsw.org Thu Aug 1 01:55:31 2013 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Thu, 1 Aug 2013 00:55:31 +0100 Subject: [csw-maintainers] Python 2.7 In-Reply-To: <86604CBF-48B3-4F6C-ACE4-51A71CBD6568@opencsw.org> References:

<86604CBF-48B3-4F6C-ACE4-51A71CBD6568@opencsw.org> Message-ID: 2013/7/31 Dagobert Michelsen > I followed the discussion on cross-version modules and the more I think about it > the more I think it would be better to clearly separate modules for different > Python versions. If you already built them with modulations I don't see the > point in putting them all in one package instead of having the old (2.6) > CSWpy- and the new CSWpy27- and CSWpy33- modules. The only possible benefit > I see is that people who are using 2.6 can pkgutil update and switch to 2.7 > after all has been rebuilt. But that can be achieved with a online shellscript > installing CSWpy27- for all CSWpy- modules. One argument for keeping the CSWpy- prefix is that we start with one 2.x version (2.6) and we eventually want to end up with one 2.x version (2.7). When we go from 2.6 to 2.7, we can introduce the CSWpy27- packages, but there eventually would only be CSWpy27- packages and none of CSWpy-. I think that would be just annoyance for our users. If we can wiggle our way through from 2.6 into 2.7 without messing around with package names, it's better and smoother for our users. I'm curious if anyone will object to my idea to drop the dependency on the interpreter. Maciej From yann at pleiades.fr.eu.org Thu Aug 1 09:21:28 2013 From: yann at pleiades.fr.eu.org (Yann Rouillard) Date: Thu, 1 Aug 2013 09:21:28 +0200 Subject: [csw-maintainers] Python 2.7 In-Reply-To: References:

<86604CBF-48B3-4F6C-ACE4-51A71CBD6568@opencsw.org> Message-ID: 2013/8/1 Maciej (Matchek) Blizi?ski > 2013/7/31 Dagobert Michelsen > > I followed the discussion on cross-version modules and the more I think > about it > > the more I think it would be better to clearly separate modules for > different > > Python versions. If you already built them with modulations I don't see > the > > point in putting them all in one package instead of having the old (2.6) > > CSWpy- and the new CSWpy27- and CSWpy33- modules. The only possible > benefit > > I see is that people who are using 2.6 can pkgutil update and switch to > 2.7 > > after all has been rebuilt. But that can be achieved with a online > shellscript > > installing CSWpy27- for all CSWpy- modules. > > One argument for keeping the CSWpy- prefix is that we start with one > 2.x version (2.6) and we eventually want to end up with one 2.x > version (2.7). When we go from 2.6 to 2.7, we can introduce the > CSWpy27- packages, but there eventually would only be CSWpy27- > packages and none of CSWpy-. I think that would be just annoyance for > our users. If we can wiggle our way through from 2.6 into 2.7 without > messing around with package names, it's better and smoother for our > users. > I don't see this as a major annoyance. After all, users have to clean the obsolete packages on their system, that is not something that is done automatically when a package is dropped from the opencsw catalog. One advantage for having a different prefix is that it will allow users to keep their obsolete 2.6 python module on their system if they want to, whereas if we have only one package CSWpy-, the day we decide to stop shipping python 2.6, they will suddenly disappear. This is not something we officially support, but I think this is nice for users to know that once they installed or compiled something relying on a opencsw library/module, they can be nearly sure it will work as long as they don't remove the package. I personnally also like consistency. I didn't understand clearly how python 3 modules will be handled. Will they all have a CSWpy33- prefix ? Will we have the same kind of problem during upgrade or is the situation different with python 3 ? > I'm curious if anyone will object to my idea to drop the dependency on > the interpreter. > The implicit contract is that when you pkgutil -i something, everything will be installed so that it will work properly. That being said, I don't think this is as big problem because: - if a user manually installs a module, he is supposed to know that a python module needs python and have probably already installed python, - if a python program need a python module, he also needs for itself the python interpreter so there is no dependency problem. I think this would be a compromise considering the fact that we don't have a dependency system with virtual dependency (where we can say that a package depends on any python interpreter < 3 and >= 2.6) Yann > > Maciej > _______________________________________________ > maintainers mailing list > maintainers at lists.opencsw.org > https://lists.opencsw.org/mailman/listinfo/maintainers > .:: This mailing list's archive is public. ::. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From maciej at opencsw.org Thu Aug 1 13:06:45 2013 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Thu, 1 Aug 2013 12:06:45 +0100 Subject: [csw-maintainers] Python 2.7 In-Reply-To: References:

<86604CBF-48B3-4F6C-ACE4-51A71CBD6568@opencsw.org> Message-ID: 2013/8/1 Yann Rouillard : > > 2013/8/1 Maciej (Matchek) Blizi?ski > >> 2013/7/31 Dagobert Michelsen >> > I followed the discussion on cross-version modules and the more I think >> > about it >> > the more I think it would be better to clearly separate modules for >> > different >> > Python versions. If you already built them with modulations I don't see >> > the >> > point in putting them all in one package instead of having the old (2.6) >> > CSWpy- and the new CSWpy27- and CSWpy33- modules. The only possible >> > benefit >> > I see is that people who are using 2.6 can pkgutil update and switch to >> > 2.7 >> > after all has been rebuilt. But that can be achieved with a online >> > shellscript >> > installing CSWpy27- for all CSWpy- modules. >> >> One argument for keeping the CSWpy- prefix is that we start with one >> 2.x version (2.6) and we eventually want to end up with one 2.x >> version (2.7). When we go from 2.6 to 2.7, we can introduce the >> CSWpy27- packages, but there eventually would only be CSWpy27- >> packages and none of CSWpy-. I think that would be just annoyance for >> our users. If we can wiggle our way through from 2.6 into 2.7 without >> messing around with package names, it's better and smoother for our >> users. > > > I don't see this as a major annoyance. After all, users have to clean the > obsolete packages on their system, that is not something that is done > automatically when a package is dropped from the opencsw catalog. > > One advantage for having a different prefix is that it will allow users to > keep their obsolete 2.6 python module on their system if they want to, > whereas if we have only one package CSWpy-, the day we decide to stop > shipping python 2.6, they will suddenly disappear. > This is not something we officially support, but I think this is nice for > users to know that once they installed or compiled something relying on a > opencsw library/module, they can be nearly sure it will work as long as they > don't remove the package. We will need to kill Python 2.6 at some point. It probably won't be this year, but it eventually has to happen. We should focus on discussing when it will happen and how we'll handle it. We will probably keep Python 2.6 in one catalog release, and kill it in another. Users who want to stick with 2.6 will have the option of staying with an old catalog as long as they want. > I personnally also like consistency. I didn't understand clearly how python > 3 modules will be handled. Will they all have a CSWpy33- prefix ? Will we > have the same kind of problem during upgrade or is the situation different > with python 3 ? Python 3 is not backward compatible, so modules will live in a different place. The main question is whether we will make the module installation path specific to the minor version, or only to the major version. In other words, will it be /opt/csw/lib/python3.3 or something like /opt/csw/share/python3. Debian is doing the latter. We haven't really thought about Python 3 handling yet. >> I'm curious if anyone will object to my idea to drop the dependency on >> the interpreter. > > > The implicit contract is that when you pkgutil -i something, everything will > be installed so that it will work properly. > That being said, I don't think this is as big problem because: > - if a user manually installs a module, he is supposed to know that a > python module needs python and have probably already installed python, > - if a python program need a python module, he also needs for itself the > python interpreter so there is no dependency problem. > > I think this would be a compromise considering the fact that we don't have a > dependency system with virtual dependency (where we can say that a package > depends on any python interpreter < 3 and >= 2.6) That's my thinking as well. Unless anyone objects, I'll make it happen soon. Maciej From yann at pleiades.fr.eu.org Thu Aug 1 14:29:31 2013 From: yann at pleiades.fr.eu.org (Yann Rouillard) Date: Thu, 1 Aug 2013 14:29:31 +0200 Subject: [csw-maintainers] Python 2.7 In-Reply-To: References:

<86604CBF-48B3-4F6C-ACE4-51A71CBD6568@opencsw.org>

Message-ID: 2013/8/1 Maciej (Matchek) Blizi?ski > > >> One argument for keeping the CSWpy- prefix is that we start with one > >> 2.x version (2.6) and we eventually want to end up with one 2.x > >> version (2.7). When we go from 2.6 to 2.7, we can introduce the > >> CSWpy27- packages, but there eventually would only be CSWpy27- > >> packages and none of CSWpy-. I think that would be just annoyance for > >> our users. If we can wiggle our way through from 2.6 into 2.7 without > >> messing around with package names, it's better and smoother for our > >> users. > > > > > > I don't see this as a major annoyance. After all, users have to clean the > > obsolete packages on their system, that is not something that is done > > automatically when a package is dropped from the opencsw catalog. > > > > One advantage for having a different prefix is that it will allow users > to > > keep their obsolete 2.6 python module on their system if they want to, > > whereas if we have only one package CSWpy-, the day we decide to stop > > shipping python 2.6, they will suddenly disappear. > > This is not something we officially support, but I think this is nice for > > users to know that once they installed or compiled something relying on a > > opencsw library/module, they can be nearly sure it will work as long as > they > > don't remove the package. > > We will need to kill Python 2.6 at some point. It probably won't be > this year, but it eventually has to happen. We should focus on > discussing when it will happen and how we'll handle it. We will > probably keep Python 2.6 in one catalog release, and kill it in > another. Users who want to stick with 2.6 will have the option of > staying with an old catalog as long as they want. > Yes that's something we could say. We could also let users keep the old version of the package even if they are using a more recent catalog. Thanks to having renamed libraries package based on their soname, that's something that is possible for libraries and I personnally think it's a good thing. For example, if someone compiled a binary against libssl0.9.8, they will not be forced to stick to an old catalog just because of that binary (a binary that might not even be recompiled against libssl1.0.0). They will be able to move on to a more recent catalog while keeping the obsolete libssl0.9.8 package installed. I would think we could apply the same logic to python packages. > > > I personnally also like consistency. I didn't understand clearly how > python > > 3 modules will be handled. Will they all have a CSWpy33- prefix ? Will we > > have the same kind of problem during upgrade or is the situation > different > > with python 3 ? > > Python 3 is not backward compatible, so modules will live in a > different place. The main question is whether we will make the module > installation path specific to the minor version, or only to the major > version. In other words, will it be /opt/csw/lib/python3.3 or > something like /opt/csw/share/python3. Debian is doing the latter. We > haven't really thought about Python 3 handling yet. > Ok, maybe we should try to include python 3 in the reflection to be sure it doesn't bring some new problem. This way we could define a consistent policy for Python. If I understand well, we will prefix all python 3 modules with CSWpy33- our CSWpy3- ? It seems for python 3, they tried to define a stable ABI / API subset: http://www.python.org/dev/peps/pep-0384/ Yann -------------- next part -------------- An HTML attachment was scrubbed... URL: From maciej at opencsw.org Thu Aug 1 14:57:35 2013 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Thu, 1 Aug 2013 13:57:35 +0100 Subject: [csw-maintainers] Python 2.7 In-Reply-To: References:

<86604CBF-48B3-4F6C-ACE4-51A71CBD6568@opencsw.org>

Message-ID: 2013/8/1 Yann Rouillard : > Thanks to having renamed libraries package based on their soname, that's > something that is possible for libraries and I personnally think it's a good > thing. > For example, if someone compiled a binary against libssl0.9.8, they will not > be forced to stick to an old catalog just because of that binary (a binary > that might not even be recompiled against libssl1.0.0). > They will be able to move on to a more recent catalog while keeping the > obsolete libssl0.9.8 package installed. > > I would think we could apply the same logic to python packages. Yes, that's an option. For every CSWpy- package we would now create CSWpy26- and CSWpy27- package, and the old CSWpy- would become a stub, pulling in the other two. I'm guessing Peter would object to that on the basis of catalog churn. I can grant that it would be on some level transparent and clean. We just need to decide which way we're going. I was thinking that not splitting each Python package into three would be a path of less resistance. I'll move the Python 3 discussion to a separate thread. Maciej From pfelecan at opencsw.org Thu Aug 1 10:42:17 2013 From: pfelecan at opencsw.org (Peter FELECAN) Date: Thu, 01 Aug 2013 10:42:17 +0200 Subject: [csw-maintainers] Python 2.7 In-Reply-To: (Yann Rouillard's message of "Thu, 1 Aug 2013 09:21:28 +0200") References:

<86604CBF-48B3-4F6C-ACE4-51A71CBD6568@opencsw.org> Message-ID: Yann Rouillard writes: > 2013/8/1 Maciej (Matchek) Blizi?ski > >> 2013/7/31 Dagobert Michelsen >> > I followed the discussion on cross-version modules and the more I think >> about it >> > the more I think it would be better to clearly separate modules for >> different >> > Python versions. If you already built them with modulations I don't see >> the >> > point in putting them all in one package instead of having the old (2.6) >> > CSWpy- and the new CSWpy27- and CSWpy33- modules. The only possible >> benefit >> > I see is that people who are using 2.6 can pkgutil update and switch to >> 2.7 >> > after all has been rebuilt. But that can be achieved with a online >> shellscript >> > installing CSWpy27- for all CSWpy- modules. >> >> One argument for keeping the CSWpy- prefix is that we start with one >> 2.x version (2.6) and we eventually want to end up with one 2.x >> version (2.7). When we go from 2.6 to 2.7, we can introduce the >> CSWpy27- packages, but there eventually would only be CSWpy27- >> packages and none of CSWpy-. I think that would be just annoyance for >> our users. If we can wiggle our way through from 2.6 into 2.7 without >> messing around with package names, it's better and smoother for our >> users. >> > > I don't see this as a major annoyance. After all, users have to clean the > obsolete packages on their system, that is not something that is done > automatically when a package is dropped from the opencsw catalog. > > One advantage for having a different prefix is that it will allow users to > keep their obsolete 2.6 python module on their system if they want to, > whereas if we have only one package CSWpy-, the day we decide to stop > shipping python 2.6, they will suddenly disappear. > This is not something we officially support, but I think this is nice for > users to know that once they installed or compiled something relying on a > opencsw library/module, they can be nearly sure it will work as long as > they don't remove the package. > > I personnally also like consistency. I didn't understand clearly how python > 3 modules will be handled. Will they all have a CSWpy33- prefix ? Will we > have the same kind of problem during upgrade or is the situation different > with python 3 ? What people need to understand is that a 2.6 non binary module can be run by a 2.7 interpreter. The reverse is not always true. This is why I proposed to replace 2.6 by 2.7 in our next transition from unstable to a named catalog. This is not to be confused with the major incompatibilities between 2.x and 3.x where using a different prefix is required. -- Peter From pfelecan at opencsw.org Thu Aug 1 09:27:23 2013 From: pfelecan at opencsw.org (Peter FELECAN) Date: Thu, 01 Aug 2013 09:27:23 +0200 Subject: [csw-maintainers] Python 2.7 In-Reply-To: ("Maciej (Matchek) =?utf-8?Q?Blizi=C5=84ski=22's?= message of "Thu, 1 Aug 2013 00:55:31 +0100") References:

<86604CBF-48B3-4F6C-ACE4-51A71CBD6568@opencsw.org> Message-ID: "Maciej (Matchek) Blizi?ski" writes: > 2013/7/31 Dagobert Michelsen >> I followed the discussion on cross-version modules and the more I think about it >> the more I think it would be better to clearly separate modules for different >> Python versions. If you already built them with modulations I don't see the >> point in putting them all in one package instead of having the old (2.6) >> CSWpy- and the new CSWpy27- and CSWpy33- modules. The only possible benefit >> I see is that people who are using 2.6 can pkgutil update and switch to 2.7 >> after all has been rebuilt. But that can be achieved with a online shellscript >> installing CSWpy27- for all CSWpy- modules. > > One argument for keeping the CSWpy- prefix is that we start with one > 2.x version (2.6) and we eventually want to end up with one 2.x > version (2.7). When we go from 2.6 to 2.7, we can introduce the > CSWpy27- packages, but there eventually would only be CSWpy27- > packages and none of CSWpy-. I think that would be just annoyance for > our users. If we can wiggle our way through from 2.6 into 2.7 without > messing around with package names, it's better and smoother for our > users. Completely agree as the target is to have 2.7 as the next 2.x stable Python interpreter, when we will transition from the next unstable to a named catalog. > I'm curious if anyone will object to my idea to drop the dependency on > the interpreter. I'm rather opposed to it as it transgress the fundamental property of explicit dependency declaration. This can also create havoc, especially if a 2.7 module is tried on a 2.6 only installation. -- Peter From yann at pleiades.fr.eu.org Thu Aug 1 15:58:58 2013 From: yann at pleiades.fr.eu.org (Yann Rouillard) Date: Thu, 1 Aug 2013 15:58:58 +0200 Subject: [csw-maintainers] Python 2.7 In-Reply-To: References:

<86604CBF-48B3-4F6C-ACE4-51A71CBD6568@opencsw.org> Message-ID: 2013/8/1 Peter FELECAN > Yann Rouillard writes: > > > What people need to understand is that a 2.6 non binary module can be > run by a 2.7 interpreter. The reverse is not always true. This is why I > proposed to replace 2.6 by 2.7 in our next transition from unstable to a > named catalog. > I thought Maciej provided a counter-example with the range function where python 2.7 didn't run the code whereas python 2.6 worked. I may have missed something in this long thread, wasn't the example valid ? > > This is not to be confused with the major incompatibilities between 2.x > and 3.x where using a different prefix is required. > To keep thing consistent, I would prefer to have a CSWpy27- prefix if we have a CSWpy3- our CSWpy33- prefix. This way the user will not install a CSWpy- package while looking for a module for python 3. Yann -------------- next part -------------- An HTML attachment was scrubbed... URL: From pfelecan at opencsw.org Thu Aug 1 13:54:35 2013 From: pfelecan at opencsw.org (Peter FELECAN) Date: Thu, 01 Aug 2013 13:54:35 +0200 Subject: [csw-maintainers] Python 2.7 In-Reply-To: ("Maciej (Matchek) =?utf-8?Q?Blizi=C5=84ski=22's?= message of "Thu, 1 Aug 2013 12:06:45 +0100") References:

<86604CBF-48B3-4F6C-ACE4-51A71CBD6568@opencsw.org>

Message-ID: "Maciej (Matchek) Blizi?ski" writes: > 2013/8/1 Yann Rouillard : >> >> 2013/8/1 Maciej (Matchek) Blizi?ski >> >>> 2013/7/31 Dagobert Michelsen >>> > I followed the discussion on cross-version modules and the more I think >>> > about it >>> > the more I think it would be better to clearly separate modules for >>> > different >>> > Python versions. If you already built them with modulations I don't see >>> > the >>> > point in putting them all in one package instead of having the old (2.6) >>> > CSWpy- and the new CSWpy27- and CSWpy33- modules. The only possible >>> > benefit >>> > I see is that people who are using 2.6 can pkgutil update and switch to >>> > 2.7 >>> > after all has been rebuilt. But that can be achieved with a online >>> > shellscript >>> > installing CSWpy27- for all CSWpy- modules. >>> >>> One argument for keeping the CSWpy- prefix is that we start with one >>> 2.x version (2.6) and we eventually want to end up with one 2.x >>> version (2.7). When we go from 2.6 to 2.7, we can introduce the >>> CSWpy27- packages, but there eventually would only be CSWpy27- >>> packages and none of CSWpy-. I think that would be just annoyance for >>> our users. If we can wiggle our way through from 2.6 into 2.7 without >>> messing around with package names, it's better and smoother for our >>> users. >> >> >> I don't see this as a major annoyance. After all, users have to clean the >> obsolete packages on their system, that is not something that is done >> automatically when a package is dropped from the opencsw catalog. >> >> One advantage for having a different prefix is that it will allow users to >> keep their obsolete 2.6 python module on their system if they want to, >> whereas if we have only one package CSWpy-, the day we decide to stop >> shipping python 2.6, they will suddenly disappear. >> This is not something we officially support, but I think this is nice for >> users to know that once they installed or compiled something relying on a >> opencsw library/module, they can be nearly sure it will work as long as they >> don't remove the package. > > We will need to kill Python 2.6 at some point. It probably won't be > this year, but it eventually has to happen. We should focus on > discussing when it will happen and how we'll handle it. We will > probably keep Python 2.6 in one catalog release, and kill it in > another. Users who want to stick with 2.6 will have the option of > staying with an old catalog as long as they want. > >> I personnally also like consistency. I didn't understand clearly how python >> 3 modules will be handled. Will they all have a CSWpy33- prefix ? Will we >> have the same kind of problem during upgrade or is the situation different >> with python 3 ? > > Python 3 is not backward compatible, so modules will live in a > different place. The main question is whether we will make the module > installation path specific to the minor version, or only to the major > version. In other words, will it be /opt/csw/lib/python3.3 or > something like /opt/csw/share/python3. Debian is doing the latter. We > haven't really thought about Python 3 handling yet. Of course is the path as is orthogonal with 2.x path. >>> I'm curious if anyone will object to my idea to drop the dependency on >>> the interpreter. >> >> >> The implicit contract is that when you pkgutil -i something, everything will >> be installed so that it will work properly. >> That being said, I don't think this is as big problem because: >> - if a user manually installs a module, he is supposed to know that a >> python module needs python and have probably already installed python, >> - if a python program need a python module, he also needs for itself the >> python interpreter so there is no dependency problem. >> >> I think this would be a compromise considering the fact that we don't have a >> dependency system with virtual dependency (where we can say that a package >> depends on any python interpreter < 3 and >= 2.6) > > That's my thinking as well. Unless anyone objects, I'll make it happen soon. As told before, I object. -- Peter From maciej at opencsw.org Thu Aug 1 16:16:09 2013 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Thu, 1 Aug 2013 15:16:09 +0100 Subject: [csw-maintainers] Python 3.x Message-ID: 2013/8/1 Yann Rouillard : > Ok, maybe we should try to include python 3 in the reflection to be sure it > doesn't bring some new problem. This way we could define a consistent policy > for Python. > > If I understand well, we will prefix all python 3 modules with CSWpy33- our > CSWpy3- ? I was thinking CSWpy3-. Before we do anything, let's (as always) look closer at what's Debian doing and why. > It seems for python 3, they tried to define a stable ABI / API subset: > http://www.python.org/dev/peps/pep-0384/ My current working assumption is that we will have one module location for all Python 3 minor versions. It's just the question of figuring out a way the module build scripts to put files where we want them. Maciej From maciej at opencsw.org Thu Aug 1 16:30:00 2013 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Thu, 1 Aug 2013 15:30:00 +0100 Subject: [csw-maintainers] Python 2.7 In-Reply-To: References:

<86604CBF-48B3-4F6C-ACE4-51A71CBD6568@opencsw.org> Message-ID: 2013/8/1 Peter FELECAN : >> I'm curious if anyone will object to my idea to drop the dependency on >> the interpreter. > > I'm rather opposed to it as it transgress the fundamental property of > explicit dependency declaration. I understand that your objection is principled rather than pragmatic, right? > This can also create havoc, especially > if a 2.7 module is tried on a 2.6 only installation. I don't know, what exactly do you have in mind? Can you give a concrete example? From pfelecan at opencsw.org Thu Aug 1 17:25:34 2013 From: pfelecan at opencsw.org (Peter FELECAN) Date: Thu, 01 Aug 2013 17:25:34 +0200 Subject: [csw-maintainers] Python 2.7 In-Reply-To: ("Maciej (Matchek) =?utf-8?Q?Blizi=C5=84ski=22's?= message of "Thu, 1 Aug 2013 15:30:00 +0100") References:

<86604CBF-48B3-4F6C-ACE4-51A71CBD6568@opencsw.org>

Message-ID: "Maciej (Matchek) Blizi?ski" writes: > 2013/8/1 Peter FELECAN : >>> I'm curious if anyone will object to my idea to drop the dependency on >>> the interpreter. >> >> I'm rather opposed to it as it transgress the fundamental property of >> explicit dependency declaration. > > I understand that your objection is principled rather than pragmatic, right? I would say a principled pragmatism :-) >> This can also create havoc, especially >> if a 2.7 module is tried on a 2.6 only installation. > > I don't know, what exactly do you have in mind? Can you give a concrete example? If one of the 2.7 modules has code using a set literal, e.g. {'0,'1'} instead of set('0','1') it will fail in 2.6 If one of the 2.6 modules has code using a set literal, e.g. set('0','1') instead of {'0,'1'} it will work in 2.7 This is what we call ascendant compatibility, isn't it? -- Peter From pfelecan at opencsw.org Thu Aug 1 17:34:08 2013 From: pfelecan at opencsw.org (Peter FELECAN) Date: Thu, 01 Aug 2013 17:34:08 +0200 Subject: [csw-maintainers] Python 2.7 In-Reply-To: (Yann Rouillard's message of "Thu, 1 Aug 2013 15:58:58 +0200") References:

<86604CBF-48B3-4F6C-ACE4-51A71CBD6568@opencsw.org> Message-ID: Yann Rouillard writes: > 2013/8/1 Peter FELECAN > >> Yann Rouillard writes: >> > >> What people need to understand is that a 2.6 non binary module can be >> run by a 2.7 interpreter. The reverse is not always true. This is why I >> proposed to replace 2.6 by 2.7 in our next transition from unstable to a >> named catalog. >> > > I thought Maciej provided a counter-example with the range function where > python 2.7 didn't run the code whereas python 2.6 worked. I may have missed > something in this long thread, wasn't the example valid ? The example referred to compiled code if my memory is good for something in this hot weather... BTW, we didn't decided on the delivery of .pyc and .pyo instead of compiling them at installation time. And for this I'm sure that I showed the proof. >> >> This is not to be confused with the major incompatibilities between 2.x >> and 3.x where using a different prefix is required. >> > > To keep thing consistent, I would prefer to have a CSWpy27- prefix if we > have a CSWpy3- our CSWpy33- prefix. > This way the user will not install a CSWpy- package while looking for a > module for python 3. First of all, the prefix is/should be CSWpy3 as Debian and tutti quanti. Having a CSWpy26- and CSWpy27- prefix is redundantly ugly... What about having CSWpy2- for the new packages being them 2.7 or modulated for 2.6 and 2.7. The new packages will stub the previous ones. This can be done by a scripted rebuild (easy to say, more manual work intensive to do). Eventually we have a coherent, orthogonal universe. Heh? -- Peter From pfelecan at opencsw.org Thu Aug 1 17:38:42 2013 From: pfelecan at opencsw.org (Peter FELECAN) Date: Thu, 01 Aug 2013 17:38:42 +0200 Subject: [csw-maintainers] Python 3.x In-Reply-To: ("Maciej (Matchek) =?utf-8?Q?Blizi=C5=84ski=22's?= message of "Thu, 1 Aug 2013 15:16:09 +0100") References: Message-ID: "Maciej (Matchek) Blizi?ski" writes: > 2013/8/1 Yann Rouillard : >> Ok, maybe we should try to include python 3 in the reflection to be sure it >> doesn't bring some new problem. This way we could define a consistent policy >> for Python. >> >> If I understand well, we will prefix all python 3 modules with CSWpy33- our >> CSWpy3- ? > > I was thinking CSWpy3-. > > Before we do anything, let's (as always) look closer at what's Debian > doing and why. They have python3 as a prefix when for 2.x they have a naked python prefix. >> It seems for python 3, they tried to define a stable ABI / API subset: >> http://www.python.org/dev/peps/pep-0384/ > > My current working assumption is that we will have one module location > for all Python 3 minor versions. It's just the question of figuring > out a way the module build scripts to put files where we want them. We want them in /opt/csw/lib/python3.3 and from the upstream build system is what they do anyway. -- Peter From maciej at opencsw.org Thu Aug 1 17:52:10 2013 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Thu, 1 Aug 2013 16:52:10 +0100 Subject: [csw-maintainers] Python 2.7 In-Reply-To: References:

<86604CBF-48B3-4F6C-ACE4-51A71CBD6568@opencsw.org>

Message-ID: 2013/8/1 Peter FELECAN > > "Maciej (Matchek) Blizi?ski" writes: > > > 2013/8/1 Peter FELECAN : > >>> I'm curious if anyone will object to my idea to drop the dependency on > >>> the interpreter. > >> > >> I'm rather opposed to it as it transgress the fundamental property of > >> explicit dependency declaration. > > > > I understand that your objection is principled rather than pragmatic, right? > > I would say a principled pragmatism :-) I honestly can't think of a realistic failure mode. Somebody forgets to install the interpreter and expects to use the module? Come on! :-) > >> This can also create havoc, especially > >> if a 2.7 module is tried on a 2.6 only installation. > > > > I don't know, what exactly do you have in mind? Can you give a concrete example? > > If one of the 2.7 modules has code using a set literal, e.g. {'0,'1'} > instead of set('0','1') it will fail in 2.6 When a module has a piece of code not compatible with the 2.6 interpreter, the module will fail to build and we will not push it out. We will have to change the module build recipe to only build for 2.7, so if you install the CSWpy- package and try to run import in the 2.6 interpreter, you'll get ImportError. Will the module work in 2.6? No, but it's by design (by upstream). Will it wreak havoc? I don't see why it would. > If one of the 2.6 modules has code using a set literal, > e.g. set('0','1') instead of {'0,'1'} it will work in 2.7 > > This is what we call ascendant compatibility, isn't it? Yes, but I don't see the connection / your reasoning. Let's assume we have module called foo, with code compatible with 2.6 and 2.7. My proposed layout is: CSWpython - install or not install as you wish CSWpython27 - install or not install as you wish CSWpy-foo - when you install it, it will work fine with CSWpython (if installed) and / or CSWpython27 (if installed). If you install both, it will work with both. That's all. Everything works as expected. I don't see what's wrong with this setup. Maciej From maciej at opencsw.org Thu Aug 1 17:57:18 2013 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Thu, 1 Aug 2013 16:57:18 +0100 Subject: [csw-maintainers] Python 3.x In-Reply-To: References: Message-ID: 2013/8/1 Peter FELECAN : > They have python3 as a prefix when for 2.x they have a naked python > prefix. > >>> It seems for python 3, they tried to define a stable ABI / API subset: >>> http://www.python.org/dev/peps/pep-0384/ >> >> My current working assumption is that we will have one module location >> for all Python 3 minor versions. It's just the question of figuring >> out a way the module build scripts to put files where we want them. > > We want them in /opt/csw/lib/python3.3 and from the upstream build > system is what they do anyway. That's what's up for debate. When Python 3.4 comes along, it will be backward compatible with Python 3.3. But if we keep modules in /opt/csw/lib/python3.3, Python 3.4 will not see them, unless we do something. We would either need to patch Python 3.4 to look into the 3.3 library directory (Is that good? I think not, it seems ugly. Prove me wrong if you wish!), or we will have to rebuild all Python 3 modules to support 3.3 and 3.4. Why not have a shared Python 3 space instead? Maciej From pfelecan at opencsw.org Thu Aug 1 18:46:03 2013 From: pfelecan at opencsw.org (Peter FELECAN) Date: Thu, 01 Aug 2013 18:46:03 +0200 Subject: [csw-maintainers] Python 2.7 In-Reply-To: ("Maciej (Matchek) =?utf-8?Q?Blizi=C5=84ski=22's?= message of "Thu, 1 Aug 2013 16:52:10 +0100") References:

<86604CBF-48B3-4F6C-ACE4-51A71CBD6568@opencsw.org>

Message-ID: "Maciej (Matchek) Blizi?ski" writes: > CSWpython - install or not install as you wish > CSWpython27 - install or not install as you wish > CSWpy-foo - when you install it, it will work fine with CSWpython (if > installed) and / or CSWpython27 (if installed). If you install both, > it will work with both. > > That's all. Everything works as expected. I don't see what's wrong > with this setup. One thing that I think of: by default, 2.6 is /opt/csw/bin/python. If a module doesn't use a shebang or other wizardry it will fail because it needs 2.7 but gets 2.6 -- Peter From pfelecan at opencsw.org Thu Aug 1 18:49:13 2013 From: pfelecan at opencsw.org (Peter FELECAN) Date: Thu, 01 Aug 2013 18:49:13 +0200 Subject: [csw-maintainers] Python 3.x In-Reply-To: ("Maciej (Matchek) =?utf-8?Q?Blizi=C5=84ski=22's?= message of "Thu, 1 Aug 2013 16:57:18 +0100") References:

Message-ID: "Maciej (Matchek) Blizi?ski" writes: > 2013/8/1 Peter FELECAN : >> They have python3 as a prefix when for 2.x they have a naked python >> prefix. >> >>>> It seems for python 3, they tried to define a stable ABI / API subset: >>>> http://www.python.org/dev/peps/pep-0384/ >>> >>> My current working assumption is that we will have one module location >>> for all Python 3 minor versions. It's just the question of figuring >>> out a way the module build scripts to put files where we want them. >> >> We want them in /opt/csw/lib/python3.3 and from the upstream build >> system is what they do anyway. > > That's what's up for debate. When Python 3.4 comes along, it will be > backward compatible with Python 3.3. But if we keep modules in > /opt/csw/lib/python3.3, Python 3.4 will not see them, unless we do > something. We would either need to patch Python 3.4 to look into the > 3.3 library directory (Is that good? I think not, it seems ugly. Prove > me wrong if you wish!), or we will have to rebuild all Python 3 > modules to support 3.3 and 3.4. Why not have a shared Python 3 space > instead? I cannot prove you wrong on an aesthetic consideration... I'm not opposed to a shared space as per Debian, we already discussed it but stalled on pre-compiled components, i.e. .pyc and .pyo But, as yourself showed, the shared space is for compiled stuff. -- Peter From maciej at opencsw.org Thu Aug 1 18:56:24 2013 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Thu, 1 Aug 2013 17:56:24 +0100 Subject: [csw-maintainers] Python 2.7 In-Reply-To: References:

<86604CBF-48B3-4F6C-ACE4-51A71CBD6568@opencsw.org>