Hi all, I know I've been promising this for quite some time to several people, so I finally managed to put together a proposal for packaging Python 3 in EPEL 7 (it'd also scale to EPEL 6 for that matter). I've created a wiki page [1] with the proposal and I'd like to hear comments and thoughts on it. There are some TODOs and variants in few places - I'd like to hear your opinions on these, or perhaps suggestions on better approaches. I'll create new documents with the updated proposal at some points during the discussion, so that people can easily see where the proposal is going without having to compare wiki revisions.
Is there any other list/interested parties that should be put in CC of this mail? If so, please feel free to respond and do that yourself.
Thanks!
On 12/10/2014 03:48 AM, Bohuslav Kabrda wrote:
Hi all, I know I've been promising this for quite some time to several people, so I finally managed to put together a proposal for packaging Python 3 in EPEL 7 (it'd also scale to EPEL 6 for that matter). I've created a wiki page [1] with the proposal and I'd like to hear comments and thoughts on it. There are some TODOs and variants in few places - I'd like to hear your opinions on these, or perhaps suggestions on better approaches. I'll create new documents with the updated proposal at some points during the discussion, so that people can easily see where the proposal is going without having to compare wiki revisions.
Is there any other list/interested parties that should be put in CC of this mail? If so, please feel free to respond and do that yourself.
Thanks!
Nice to see some progress on this. Some comments:
- We should have /usr/bin/python3, if only for end user convenience. - I want to be able to build my EPEL python3X packages out of my existing python dist-git packages' epel7 branch.
----- Original Message -----
On 12/10/2014 03:48 AM, Bohuslav Kabrda wrote:
Hi all, I know I've been promising this for quite some time to several people, so I finally managed to put together a proposal for packaging Python 3 in EPEL 7 (it'd also scale to EPEL 6 for that matter). I've created a wiki page [1] with the proposal and I'd like to hear comments and thoughts on it. There are some TODOs and variants in few places - I'd like to hear your opinions on these, or perhaps suggestions on better approaches. I'll create new documents with the updated proposal at some points during the discussion, so that people can easily see where the proposal is going without having to compare wiki revisions.
Is there any other list/interested parties that should be put in CC of this mail? If so, please feel free to respond and do that yourself.
Thanks!
Nice to see some progress on this. Some comments:
- We should have /usr/bin/python3, if only for end user convenience.
Yeah, I agree we should have it, although for use in RPMs, I'd suggest discouraging it and instead promote usage of /usr/bin/pythonXY.
- I want to be able to build my EPEL python3X packages out of my existing
python dist-git packages' epel7 branch.
Ok, it's not my preference, I'd rather use the third option outlined in the original proposal (e.g. have separate repos for EPEL python3 packages) because of some of the downsides I see when using epel-7 branches in standard python dist-git repos. But then again, that's just my preference and if more people voice the same opinion as you, I'm fine doing it your way.
Thanks for your comments, Slavel
-- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane orion@nwra.com Boulder, CO 80301 http://www.nwra.com _______________________________________________ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
On 10 December 2014 at 03:48, Bohuslav Kabrda bkabrda@redhat.com wrote:
Hi all, I know I've been promising this for quite some time to several people, so I finally managed to put together a proposal for packaging Python 3 in EPEL 7 (it'd also scale to EPEL 6 for that matter). I've created a wiki page [1] with the proposal and I'd like to hear comments and thoughts on it. There are some TODOs and variants in few places - I'd like to hear your opinions on these, or perhaps suggestions on better approaches. I'll create new documents with the updated proposal at some points during the discussion, so that people can easily see where the proposal is going without having to compare wiki revisions.
Is there any other list/interested parties that should be put in CC of this mail? If so, please feel free to respond and do that yourself.
THis proposal looks good at first blush. I think the time for retirement of python3X to python3(X+1) can be anywhere from 6 weeks to 2 months (if that isn't too long).
Thanks!
-- Regards, Slavek Kabrda
[1] https://fedoraproject.org/wiki/User:Bkabrda/EPEL7_Python3 _______________________________________________ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
One thing to look out for would be SCL mod_wsgi. In the SCL world they name it python33-mod_wsgi. Most modules are %{SCL}-python-%{module}, but mod_wsgi is unique. To avoid conflicts, the IUS project has committed to using the suffix "u" on our packages going forward (python34u-mod_wsgi). Are you concerned at all about naming conflicts with SCL packages?
I added the IUS coredev mailing list to the CC line.
Carl George IUS Community Project
________________________________ From: epel-devel-bounces@lists.fedoraproject.org [epel-devel-bounces@lists.fedoraproject.org] on behalf of Stephen John Smoogen [smooge@gmail.com] Sent: Wednesday, December 10, 2014 02:24 PM To: EPEL Development List Subject: Re: [EPEL-devel] Proposal for Python 3 packaging in EPEL 7
On 10 December 2014 at 03:48, Bohuslav Kabrda <bkabrda@redhat.commailto:bkabrda@redhat.com> wrote: Hi all, I know I've been promising this for quite some time to several people, so I finally managed to put together a proposal for packaging Python 3 in EPEL 7 (it'd also scale to EPEL 6 for that matter). I've created a wiki page [1] with the proposal and I'd like to hear comments and thoughts on it. There are some TODOs and variants in few places - I'd like to hear your opinions on these, or perhaps suggestions on better approaches. I'll create new documents with the updated proposal at some points during the discussion, so that people can easily see where the proposal is going without having to compare wiki revisions.
Is there any other list/interested parties that should be put in CC of this mail? If so, please feel free to respond and do that yourself.
THis proposal looks good at first blush. I think the time for retirement of python3X to python3(X+1) can be anywhere from 6 weeks to 2 months (if that isn't too long).
Thanks!
-- Regards, Slavek Kabrda
[1] https://fedoraproject.org/wiki/User:Bkabrda/EPEL7_Python3 _______________________________________________ epel-devel mailing list epel-devel@lists.fedoraproject.orgmailto:epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
-- Stephen J Smoogen.
Yeah, now that it all comes back to me, naming conflicts with SCLs is probably the biggest issue. The fact SCLs weren't given a prefix is a major issue for many possible EPEL packages.
On 12/11/2014 09:46 AM, Carl George wrote:
One thing to look out for would be SCL mod_wsgi. In the SCL world they name it python33-mod_wsgi. Most modules are %{SCL}-python-%{module}, but mod_wsgi is unique. To avoid conflicts, the IUS project has committed to using the suffix "u" on our packages going forward (python34u-mod_wsgi). Are you concerned at all about naming conflicts with SCL packages?
I added the IUS coredev mailing list to the CC line.
Carl George IUS Community Project
*From:* epel-devel-bounces@lists.fedoraproject.org [epel-devel-bounces@lists.fedoraproject.org] on behalf of Stephen John Smoogen [smooge@gmail.com] *Sent:* Wednesday, December 10, 2014 02:24 PM *To:* EPEL Development List *Subject:* Re: [EPEL-devel] Proposal for Python 3 packaging in EPEL 7
On 10 December 2014 at 03:48, Bohuslav Kabrda <bkabrda@redhat.com mailto:bkabrda@redhat.com> wrote:
Hi all, I know I've been promising this for quite some time to several people, so I finally managed to put together a proposal for packaging Python 3 in EPEL 7 (it'd also scale to EPEL 6 for that matter). I've created a wiki page [1] with the proposal and I'd like to hear comments and thoughts on it. There are some TODOs and variants in few places - I'd like to hear your opinions on these, or perhaps suggestions on better approaches. I'll create new documents with the updated proposal at some points during the discussion, so that people can easily see where the proposal is going without having to compare wiki revisions. Is there any other list/interested parties that should be put in CC of this mail? If so, please feel free to respond and do that yourself.THis proposal looks good at first blush. I think the time for retirement of python3X to python3(X+1) can be anywhere from 6 weeks to 2 months (if that isn't too long).
Thanks! -- Regards, Slavek Kabrda [1] https://fedoraproject.org/wiki/User:Bkabrda/EPEL7_Python3 _______________________________________________ epel-devel mailing list epel-devel@lists.fedoraproject.org <mailto:epel-devel@lists.fedoraproject.org> https://admin.fedoraproject.org/mailman/listinfo/epel-devel-- Stephen J Smoogen.
epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
----- Original Message -----
Yeah, now that it all comes back to me, naming conflicts with SCLs is probably the biggest issue. The fact SCLs weren't given a prefix is a major issue for many possible EPEL packages.
On 12/11/2014 09:46 AM, Carl George wrote:
One thing to look out for would be SCL mod_wsgi. In the SCL world they name it python33-mod_wsgi. Most modules are %{SCL}-python-%{module}, but mod_wsgi is unique. To avoid conflicts, the IUS project has committed to using the suffix "u" on our packages going forward (python34u-mod_wsgi). Are you concerned at all about naming conflicts with SCL packages?
I added the IUS coredev mailing list to the CC line.
Carl George IUS Community Project
Good points, both. The thing that I forgot to mention is that it was decided that new RHSCL collections will be prefixed with "rh-", hence giving "rh-python34" and similar. Therefore we don't have to be afraid of any naming conflicts - if and when Python 3.4 is packaged for RHSCL, it won't conflict with the proposed python34 EPEL stack (not now, not in future).
Slavek
*From:* epel-devel-bounces@lists.fedoraproject.org [epel-devel-bounces@lists.fedoraproject.org] on behalf of Stephen John Smoogen [smooge@gmail.com] *Sent:* Wednesday, December 10, 2014 02:24 PM *To:* EPEL Development List *Subject:* Re: [EPEL-devel] Proposal for Python 3 packaging in EPEL 7
On 10 December 2014 at 03:48, Bohuslav Kabrda <bkabrda@redhat.com mailto:bkabrda@redhat.com> wrote:
Hi all, I know I've been promising this for quite some time to several people, so I finally managed to put together a proposal for packaging Python 3 in EPEL 7 (it'd also scale to EPEL 6 for that matter). I've created a wiki page [1] with the proposal and I'd like to hear comments and thoughts on it. There are some TODOs and variants in few places - I'd like to hear your opinions on these, or perhaps suggestions on better approaches. I'll create new documents with the updated proposal at some points during the discussion, so that people can easily see where the proposal is going without having to compare wiki revisions. Is there any other list/interested parties that should be put in CC of this mail? If so, please feel free to respond and do that yourself.THis proposal looks good at first blush. I think the time for retirement of python3X to python3(X+1) can be anywhere from 6 weeks to 2 months (if that isn't too long).
Thanks! -- Regards, Slavek Kabrda [1] https://fedoraproject.org/wiki/User:Bkabrda/EPEL7_Python3 _______________________________________________ epel-devel mailing list epel-devel@lists.fedoraproject.org <mailto:epel-devel@lists.fedoraproject.org> https://admin.fedoraproject.org/mailman/listinfo/epel-devel-- Stephen J Smoogen.
epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
-- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane orion@nwra.com Boulder, CO 80301 http://www.nwra.com _______________________________________________ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
----- Original Message -----
Hi all, I know I've been promising this for quite some time to several people, so I finally managed to put together a proposal for packaging Python 3 in EPEL 7 (it'd also scale to EPEL 6 for that matter). I've created a wiki page [1] with the proposal and I'd like to hear comments and thoughts on it. There are some TODOs and variants in few places - I'd like to hear your opinions on these, or perhaps suggestions on better approaches. I'll create new documents with the updated proposal at some points during the discussion, so that people can easily see where the proposal is going without having to compare wiki revisions.
Is there any other list/interested parties that should be put in CC of this mail? If so, please feel free to respond and do that yourself.
Thanks!
-- Regards, Slavek Kabrda
[1] https://fedoraproject.org/wiki/User:Bkabrda/EPEL7_Python3
Let's reiterate: - Nick Coghlan posted an interesting proposal to the discussion section in my proposal (my reaction is in the blue frame) [1]. I'd appreciate more comments on this. - From the feedback gathered on this list: - We should have /usr/bin/python3 pointing to a python3X build. The question is which one this will be during transitional periods between 3X and 3X+1. My thinking is that we should point /usr/bin/python3 to 3X+1 at the time of retiring 3X (IMO there is no ideal time to do that, so it's not really important). - As for dist-git possibilities, Orion would prefer to use current dist-git repos with epel-7 branches. It's not my preference (for reasons mentioned in the proposal), but I'm not against it if that is what others wish. - Stephen Smoogen mentioned that the transitional period during which python3X and python3X+1 exist can be anywhere from 6 weeks to 2 months. I'm starting to think that we should only specify the minimum time for which 3X will be kept. So my proposal would be sth. like "3X is kept for minimum of 6 weeks in parallel to 3X+1. After this, it is retired as soon as all stakeholders have rebuilt against 3X+1." (keeping it a bit vague is a good thing here, I think) - As I noted in one of my emails, we don't have to worry about conflicts with RHSCL. New collections from RHSCL will be named with "rh-" prefix and thus won't conflict with python3X stacks.
Since it doesn't seem that there was anything very problematic, let's discuss the points mentioned above after which I should be able to finalize the proposal and make it official (and then we could all get to building :)). I'm quite sure that we'll still hit some technical issues, e.g. macro naming for parallel stacks, but I believe we can discuss and solve these on the way.
Thanks.
On 7 January 2015 at 04:05, Bohuslav Kabrda bkabrda@redhat.com wrote:
----- Original Message -----
Hi all, I know I've been promising this for quite some time to several people,
so I
finally managed to put together a proposal for packaging Python 3 in
EPEL 7
(it'd also scale to EPEL 6 for that matter). I've created a wiki page [1] with the proposal and I'd like to hear
comments
and thoughts on it. There are some TODOs and variants in few places - I'd like to hear your opinions on these, or perhaps suggestions on better approaches. I'll create new documents with the updated proposal at some points
during the
discussion, so that people can easily see where the proposal is going without having to compare wiki revisions.
Is there any other list/interested parties that should be put in CC of
this
mail? If so, please feel free to respond and do that yourself.
Thanks!
-- Regards, Slavek Kabrda
[1] https://fedoraproject.org/wiki/User:Bkabrda/EPEL7_Python3
Let's reiterate:
- Nick Coghlan posted an interesting proposal to the discussion section in
my proposal (my reaction is in the blue frame) [1]. I'd appreciate more comments on this.
- From the feedback gathered on this list:
- We should have /usr/bin/python3 pointing to a python3X build. The
question is which one this will be during transitional periods between 3X and 3X+1. My thinking is that we should point /usr/bin/python3 to 3X+1 at the time of retiring 3X (IMO there is no ideal time to do that, so it's not really important).
- As for dist-git possibilities, Orion would prefer to use current
dist-git repos with epel-7 branches. It's not my preference (for reasons mentioned in the proposal), but I'm not against it if that is what others wish.
- Stephen Smoogen mentioned that the transitional period during which
python3X and python3X+1 exist can be anywhere from 6 weeks to 2 months. I'm starting to think that we should only specify the minimum time for which 3X will be kept. So my proposal would be sth. like "3X is kept for minimum of 6 weeks in parallel to 3X+1. After this, it is retired as soon as all stakeholders have rebuilt against 3X+1." (keeping it a bit vague is a good thing here, I think)
- As I noted in one of my emails, we don't have to worry about conflicts
with RHSCL. New collections from RHSCL will be named with "rh-" prefix and thus won't conflict with python3X stacks.
Since it doesn't seem that there was anything very problematic, let's discuss the points mentioned above after which I should be able to finalize the proposal and make it official (and then we could all get to building :)). I'm quite sure that we'll still hit some technical issues, e.g. macro naming for parallel stacks, but I believe we can discuss and solve these on the way.
Thank you for circling back on this. I was going to try and contact you today about python26 which is orphaned in EPEL-5 and was going to see if we could use the same logic for making a python27 tree for EL5 and EL6?
Thanks.
-- Regards, Slavek Kabrda
[1] https://fedoraproject.org/wiki/User_talk:Bkabrda/EPEL7_Python3#Sharing_Packa... _______________________________________________ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
On 7 January 2015 at 04:05, Bohuslav Kabrda < bkabrda@redhat.com > wrote:
----- Original Message -----
Hi all,
I know I've been promising this for quite some time to several people, so I
finally managed to put together a proposal for packaging Python 3 in EPEL 7
(it'd also scale to EPEL 6 for that matter).
I've created a wiki page [1] with the proposal and I'd like to hear comments
and thoughts on it. There are some TODOs and variants in few places - I'd
like to hear your opinions on these, or perhaps suggestions on better
approaches.
I'll create new documents with the updated proposal at some points during the
discussion, so that people can easily see where the proposal is going
without having to compare wiki revisions.
Is there any other list/interested parties that should be put in CC of this
mail? If so, please feel free to respond and do that yourself.
Thanks!
--
Regards,
Slavek Kabrda
[1] https://fedoraproject.org/wiki/User:Bkabrda/EPEL7_Python3
Let's reiterate:
- Nick Coghlan posted an interesting proposal to the discussion section in
my proposal (my reaction is in the blue frame) [1]. I'd appreciate more comments on this.
- From the feedback gathered on this list:
- We should have /usr/bin/python3 pointing to a python3X build. The
question is which one this will be during transitional periods between 3X and 3X+1. My thinking is that we should point /usr/bin/python3 to 3X+1 at the time of retiring 3X (IMO there is no ideal time to do that, so it's not really important).
- As for dist-git possibilities, Orion would prefer to use current dist-git
repos with epel-7 branches. It's not my preference (for reasons mentioned in the proposal), but I'm not against it if that is what others wish.
- Stephen Smoogen mentioned that the transitional period during which
python3X and python3X+1 exist can be anywhere from 6 weeks to 2 months. I'm starting to think that we should only specify the minimum time for which 3X will be kept. So my proposal would be sth. like "3X is kept for minimum of 6 weeks in parallel to 3X+1. After this, it is retired as soon as all stakeholders have rebuilt against 3X+1." (keeping it a bit vague is a good thing here, I think)
- As I noted in one of my emails, we don't have to worry about conflicts
with RHSCL. New collections from RHSCL will be named with "rh-" prefix and thus won't conflict with python3X stacks.
Since it doesn't seem that there was anything very problematic, let's discuss the points mentioned above after which I should be able to finalize the proposal and make it official (and then we could all get to building :)).
I'm quite sure that we'll still hit some technical issues, e.g. macro naming for parallel stacks, but I believe we can discuss and solve these on the way.
Thank you for circling back on this. I was going to try and contact you today about python26 which is orphaned in EPEL-5 and was going to see if we could use the same logic for making a python27 tree for EL5 and EL6?
Yeah, theoretically we can do that, although I'm not very keen on the idea of maintaining yet another build of Python ;) certainly not for EPEL5... Note, that one important thing to decide here what the dist-git solution will be. The EPEL5 python26 solution basically created new repos for all packages, called python26-*. That's viable for python27, since there's no python28 coming, but it's not a good solution for python3X. That's why I'd probably rather apply the same approach that we'll take for python3X in EPEL7 (whichever that will be). Also, I'm starting to think about the technical solution (read: RPM macros) to multiple Pythons, since I really don't like the python26 solution from EPEL5. I'll put my solution in a proposal next week, so that everyone can comment on that, too.
Thanks, Slavek
Thanks.
--
Regards,
Slavek Kabrda
[1] https://fedoraproject.org/wiki/User_talk:Bkabrda/EPEL7_Python3#Sharing_Packa...
epel-devel mailing list
epel-devel@lists.fedoraproject.org
-- Stephen J Smoogen.
epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
Thank you for circling back on this. I was going to try and contact you today about python26 which is orphaned in EPEL-5 and was going to see if we could use the same logic for making a python27 tree for EL5 and EL6?
Yeah, theoretically we can do that, although I'm not very keen on the idea of maintaining yet another build of Python ;) certainly not for EPEL5... Note, that one important thing to decide here what the dist-git solution will be. The EPEL5 python26 solution basically created new repos for all packages, called python26-*. That's viable for python27, since there's no python28 coming, but it's not a good solution for python3X. That's why I'd probably rather apply the same approach that we'll take for python3X in EPEL7 (whichever that will be). Also, I'm starting to think about the technical solution (read: RPM macros) to multiple Pythons, since I really don't like the python26 solution from EPEL5. I'll put my solution in a proposal next week, so that everyone can comment on that, too.
Thanks, Slavek
So here's a new part of the proposal that deals with specfiles/macros and how that all will work with imports from Fedora etc: https://fedoraproject.org/wiki/User:Bkabrda/EPEL7_Python3#Specfiles.2C_Macro... Something similar should be usable in EPEL 6 for python27, but I realized that situation is a bit different, since python27 is never going to be replaced by python28, so there's no need to consider two 2X stacks. I have to admit that I have very little interest (and time!) for python27 in EPEL 6, so I'll leave that proposal to someone else. As usual, all comments are appreciated!
Thanks, Slavek
On 15 January 2015 at 08:40, Bohuslav Kabrda bkabrda@redhat.com wrote:
Thank you for circling back on this. I was going to try and contact you today about python26 which is orphaned in EPEL-5 and was going to see if we could use the same logic for making a python27 tree for EL5 and EL6?
Yeah, theoretically we can do that, although I'm not very keen on the idea of maintaining yet another build of Python ;) certainly not for EPEL5... Note, that one important thing to decide here what the dist-git solution will be. The EPEL5 python26 solution basically created new repos for all packages, called python26-*. That's viable for python27, since there's no python28 coming, but it's not a good solution for python3X. That's why I'd probably rather apply the same approach that we'll take for python3X in EPEL7 (whichever that will be). Also, I'm starting to think about the technical solution (read: RPM macros) to multiple Pythons, since I really don't like the python26 solution from EPEL5. I'll put my solution in a proposal next week, so that everyone can comment on that, too.
Thanks, Slavek
So here's a new part of the proposal that deals with specfiles/macros and how that all will work with imports from Fedora etc: https://fedoraproject.org/wiki/User:Bkabrda/EPEL7_Python3#Specfiles.2C_Macro... Something similar should be usable in EPEL 6 for python27, but I realized that situation is a bit different, since python27 is never going to be replaced by python28, so there's no need to consider two 2X stacks. I have to admit that I have very little interest (and time!) for python27 in EPEL 6, so I'll leave that proposal to someone else. As usual, all comments are appreciated!
I am very interested in python27 for EPEL5 and EPEL6 so will try to work on those parts. While I don't expect a 28.. I will assume that someday someone will make one even if it is Guido on April 1 2020.
Thanks, Slavek
epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
Is the EPIC proposal totally dead? It seems like that would be a nicer and more general solution to this problem (not wanting to ship a Python 3.x stack for 10 years).
Personally I am not looking forward to maintaining more branches and/or (sub-)packages for every python3X-*.
On 8 January 2015 at 17:01, Dan Callaghan dcallagh@redhat.com wrote:
Is the EPIC proposal totally dead? It seems like that would be a nicer and more general solution to this problem (not wanting to ship a Python 3.x stack for 10 years).
The EPIC proposal needs
a) A formal proposal b) People who are willing to work on it.
I haven't had time to do a) and while I have seen a lot of "Oh I would totally use EPIC if it was around.." I haven't gotten any "Hey that sounds like an interesting hard problem. Sign me up for some pain."
Personally I am not looking forward to maintaining more branches and/or (sub-)packages for every python3X-*.
I need to understand what you mean here? Even in EPIC and SCL's there would have to be some overlap and multiple branches over time due to the fact that python, ruby, java, etc all have multiple subpackages which would need to be built for multiple releases. They may not be for a long lenght of time, but the work is not going away.
-- Dan Callaghan dcallagh@redhat.com Software Engineer, Hosted & Shared Services Red Hat, Inc.
epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
Excerpts from Stephen John Smoogen's message of 2015-01-09 10:25 +10:00:
On 8 January 2015 at 17:01, Dan Callaghan dcallagh@redhat.com wrote:
Personally I am not looking forward to maintaining more branches and/or (sub-)packages for every python3X-*.
I need to understand what you mean here? Even in EPIC and SCL's there would have to be some overlap and multiple branches over time due to the fact that python, ruby, java, etc all have multiple subpackages which would need to be built for multiple releases. They may not be for a long lenght of time, but the work is not going away.
Right, even for Fedora there are multiple branches of course, what I meant was multiple *divergent* branches.
For all my packages I prefer to keep a single spec for all branches with conditionals when necessary. Most of my packages are fairly stable and not releasing new incompatible versions too often, so most of the time I can just do one update and then all branches are a git fast-forward. The only time I have divergent branches is when a stable release needs a bug fix but rawhide has already moved to a newer incompatible version. That's fairly rare for my packages.
So that approach works fine right now because we just have python-foo and python3-foo subpackages and they can just keep rolling through as new releases are branched and old releases die off.
What I was picturing for EPEL Python 3 was that I would have to rename the subpackage to python34-foo. Then every time Python 3 is bumped I would have to rename all the subpackages to python35-foo, and then I would have divergent branches for as long as both 3.4 and 3.5 still exist. That's the situation I was complaining about.
A much better approach is what Bohuslav has come up with, a single spec that builds both python3X and python3X+1 subpackages. And we can script the mass version bumping as well. So that addresses my worries.
(The example spec makes me a bit sad with how complex and repetitive it is, but I guess there is nothing really we can do about that...)
----- Original Message -----
Excerpts from Stephen John Smoogen's message of 2015-01-09 10:25 +10:00:
On 8 January 2015 at 17:01, Dan Callaghan dcallagh@redhat.com wrote:
Personally I am not looking forward to maintaining more branches and/or (sub-)packages for every python3X-*.
I need to understand what you mean here? Even in EPIC and SCL's there would have to be some overlap and multiple branches over time due to the fact that python, ruby, java, etc all have multiple subpackages which would need to be built for multiple releases. They may not be for a long lenght of time, but the work is not going away.
Right, even for Fedora there are multiple branches of course, what I meant was multiple *divergent* branches.
For all my packages I prefer to keep a single spec for all branches with conditionals when necessary. Most of my packages are fairly stable and not releasing new incompatible versions too often, so most of the time I can just do one update and then all branches are a git fast-forward. The only time I have divergent branches is when a stable release needs a bug fix but rawhide has already moved to a newer incompatible version. That's fairly rare for my packages.
So that approach works fine right now because we just have python-foo and python3-foo subpackages and they can just keep rolling through as new releases are branched and old releases die off.
What I was picturing for EPEL Python 3 was that I would have to rename the subpackage to python34-foo. Then every time Python 3 is bumped I would have to rename all the subpackages to python35-foo, and then I would have divergent branches for as long as both 3.4 and 3.5 still exist. That's the situation I was complaining about.
A much better approach is what Bohuslav has come up with, a single spec that builds both python3X and python3X+1 subpackages. And we can script the mass version bumping as well. So that addresses my worries.
(The example spec makes me a bit sad with how complex and repetitive it is, but I guess there is nothing really we can do about that...)
I was experimenting with dynamic subpackage generation, but you need Lua for that. And while it can be done, it's actually much uglier than the way I proposed. I guess the only nice way would be to add support for dynamic subpackage generation to RPM directly. That is actually something I've wanted to propose for some time now, but didn't really get to it... Also, it's questionable that it'd get to RHEL 7 rpm, so I think we're stuck with this.
-- Dan Callaghan dcallagh@redhat.com Software Engineer, Hosted & Shared Services Red Hat, Inc.
----- Original Message -----
Is the EPIC proposal totally dead? It seems like that would be a nicer and more general solution to this problem (not wanting to ship a Python 3.x stack for 10 years).
I'm not sure about that, but I think we can align python3 in epel with EPIC even if EPIC is introduced later on.
Personally I am not looking forward to maintaining more branches and/or (sub-)packages for every python3X-*.
The way I see it, we will only maintain a single python3X-* subpackage most of the time; then, when python3X+1 is released, we will maintain two subpackages for a short period of time, until python3X is retired.
-- Dan Callaghan dcallagh@redhat.com Software Engineer, Hosted & Shared Services Red Hat, Inc.
epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
On Wed, 2015-01-07 at 06:05 -0500, Bohuslav Kabrda wrote:
----- Original Message -----
Hi all, I know I've been promising this for quite some time to several people, so I finally managed to put together a proposal for packaging Python 3 in EPEL 7 (it'd also scale to EPEL 6 for that matter). I've created a wiki page [1] with the proposal and I'd like to hear comments and thoughts on it. There are some TODOs and variants in few places - I'd like to hear your opinions on these, or perhaps suggestions on better approaches. I'll create new documents with the updated proposal at some points during the discussion, so that people can easily see where the proposal is going without having to compare wiki revisions.
Is there any other list/interested parties that should be put in CC of this mail? If so, please feel free to respond and do that yourself.
Thanks!
-- Regards, Slavek Kabrda
[1] https://fedoraproject.org/wiki/User:Bkabrda/EPEL7_Python3
Let's reiterate:
- Nick Coghlan posted an interesting proposal to the discussion section in my proposal (my reaction is in the blue frame) [1]. I'd appreciate more comments on this.
- From the feedback gathered on this list:
- We should have /usr/bin/python3 pointing to a python3X build. The question is which one this will be during transitional periods between 3X and 3X+1. My thinking is that we should point /usr/bin/python3 to 3X+1 at the time of retiring 3X (IMO there is no ideal time to do that, so it's not really important).
- As for dist-git possibilities, Orion would prefer to use current dist-git repos with epel-7 branches. It's not my preference (for reasons mentioned in the proposal), but I'm not against it if that is what others wish.
- Stephen Smoogen mentioned that the transitional period during which python3X and python3X+1 exist can be anywhere from 6 weeks to 2 months. I'm starting to think that we should only specify the minimum time for which 3X will be kept. So my proposal would be sth. like "3X is kept for minimum of 6 weeks in parallel to 3X+1. After this, it is retired as soon as all stakeholders have rebuilt against 3X+1." (keeping it a bit vague is a good thing here, I think)
- As I noted in one of my emails, we don't have to worry about conflicts with RHSCL. New collections from RHSCL will be named with "rh-" prefix and thus won't conflict with python3X stacks.
Since it doesn't seem that there was anything very problematic, let's discuss the points mentioned above after which I should be able to finalize the proposal and make it official (and then we could all get to building :)). I'm quite sure that we'll still hit some technical issues, e.g. macro naming for parallel stacks, but I believe we can discuss and solve these on the way.
A bikeshedding idea that may be controversial: aren't periods valid characters within rpm package names? If so, can't we have the package name be "python3.X" rather than "python3X". For that matter, dash characters are valid in the name, so can't we call it "python-3.X"?
This might give e.g.
python-3.4-numpy-1.5.0-1.el7 ^^^^^^^^^^^^^^^^ ^^^^^ ^^^^^ N V R
Though, for the core runtime e.g. python-3.4-3.4.0-1.el7 might seem harder to read than: python3.4-3.4.0-1.el7 or: python34-3.4.0-1.el7
Apologies for the bikeshedding Dave
----- Original Message -----
On Wed, 2015-01-07 at 06:05 -0500, Bohuslav Kabrda wrote:
----- Original Message -----
Hi all, I know I've been promising this for quite some time to several people, so I finally managed to put together a proposal for packaging Python 3 in EPEL 7 (it'd also scale to EPEL 6 for that matter). I've created a wiki page [1] with the proposal and I'd like to hear comments and thoughts on it. There are some TODOs and variants in few places - I'd like to hear your opinions on these, or perhaps suggestions on better approaches. I'll create new documents with the updated proposal at some points during the discussion, so that people can easily see where the proposal is going without having to compare wiki revisions.
Is there any other list/interested parties that should be put in CC of this mail? If so, please feel free to respond and do that yourself.
Thanks!
-- Regards, Slavek Kabrda
[1] https://fedoraproject.org/wiki/User:Bkabrda/EPEL7_Python3
Let's reiterate:
- Nick Coghlan posted an interesting proposal to the discussion section in
my proposal (my reaction is in the blue frame) [1]. I'd appreciate more comments on this.
- From the feedback gathered on this list:
question is which one this will be during transitional periods between 3X and 3X+1. My thinking is that we should point /usr/bin/python3 to 3X+1 at the time of retiring 3X (IMO there is no ideal time to do that, so it's not really important).
- We should have /usr/bin/python3 pointing to a python3X build. The
dist-git repos with epel-7 branches. It's not my preference (for reasons mentioned in the proposal), but I'm not against it if that is what others wish.
- As for dist-git possibilities, Orion would prefer to use current
python3X and python3X+1 exist can be anywhere from 6 weeks to 2 months. I'm starting to think that we should only specify the minimum time for which 3X will be kept. So my proposal would be sth. like "3X is kept for minimum of 6 weeks in parallel to 3X+1. After this, it is retired as soon as all stakeholders have rebuilt against 3X+1." (keeping it a bit vague is a good thing here, I think)
- Stephen Smoogen mentioned that the transitional period during which
with RHSCL. New collections from RHSCL will be named with "rh-" prefix and thus won't conflict with python3X stacks.
- As I noted in one of my emails, we don't have to worry about conflicts
Since it doesn't seem that there was anything very problematic, let's discuss the points mentioned above after which I should be able to finalize the proposal and make it official (and then we could all get to building :)). I'm quite sure that we'll still hit some technical issues, e.g. macro naming for parallel stacks, but I believe we can discuss and solve these on the way.
A bikeshedding idea that may be controversial: aren't periods valid characters within rpm package names? If so, can't we have the package name be "python3.X" rather than "python3X". For that matter, dash characters are valid in the name, so can't we call it "python-3.X"?
This might give e.g.
python-3.4-numpy-1.5.0-1.el7 ^^^^^^^^^^^^^^^^ ^^^^^ ^^^^^ N V R
Though, for the core runtime e.g. python-3.4-3.4.0-1.el7 might seem harder to read than: python3.4-3.4.0-1.el7 or: python34-3.4.0-1.el7
Apologies for the bikeshedding Dave
Dave, thanks for the input. Yes, it's technically possible to put both dashes and dots in package name, although I'm sort of failing to see what the benefit of doing that would be. Is this for readability only? For me, python34-something is more readable than the two variants you propose (but I understand that it's a matter of personal preference and if majority likes one of your variants, we can use it).
On 9 January 2015 at 07:38, Bohuslav Kabrda bkabrda@redhat.com wrote:
Dave, thanks for the input. Yes, it's technically possible to put both dashes and dots in package name, although I'm sort of failing to see what the benefit of doing that would be. Is this for readability only? For me, python34-something is more readable than the two variants you propose (but I understand that it's a matter of personal preference and if majority likes one of your variants, we can use it).
I can actually see a reason.. when you want python310 to replace python39 using simple parsing rules. But that is just me comparing colours on the bikeshed. [It should point south.. or you'll get the wood rot.]
-- Regards, Slavek Kabrda _______________________________________________ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
----- Original Message -----
On 9 January 2015 at 07:38, Bohuslav Kabrda < bkabrda@redhat.com > wrote:
Dave, thanks for the input.
Yes, it's technically possible to put both dashes and dots in package name, although I'm sort of failing to see what the benefit of doing that would be. Is this for readability only? For me, python34-something is more readable than the two variants you propose (but I understand that it's a matter of personal preference and if majority likes one of your variants, we can use it).
I can actually see a reason.. when you want python310 to replace python39 using simple parsing rules. But that is just me comparing colours on the bikeshed. [It should point south.. or you'll get the wood rot.]
Guido van Rossum has, several times now, expressed his aversion to having "3.10". It is most likely that there will be "3.9" and then "4.0", even if that doesn't present any huge change (like 2.6->3.0 did). [No, no, south is *obviously wrong*; moreover, it'll be metal, not wood...]
Regards,
Slavek Kabrda
-- Stephen J Smoogen.
I added a comment to the proposal discussion page to indicate I agree it's better to just go with full parallel stacks and not worry about making use of the stable ABI at this point.
I'm not familiar enough with the EPEL build infrastructure to have a strong opinion
On 01/13/2015 09:47 PM, Bohuslav Kabrda wrote:
Guido van Rossum has, several times now, expressed his aversion to having "3.10". It is most likely that there will be "3.9" and then "4.0", even if that doesn't present any huge change (like 2.6->3.0 did).
Slavek is correct that the current plan is for Python to simply go 3.9 -> 4.0 rather than continuing with the 3.x series indefinitely. The degree of change is expected to be comparable to any other X.Y -> X.Y+1 release, rather than being comparable to the 2.x -> 3.x situation. Instead, the major version bump will largely just indicate whether other code and materials have been suitably modernised to use 4.x idioms, rather than still remaining compatible with earlier, by then legacy, 3.x versions.
Tangentially related, I'm actually somewhat morbidly curious as to what's going to break when 2.7.10 is published later this year :)
[No, no, south is *obviously wrong*; moreover, it'll be metal, not wood...]
[TBH, I've always strongly favoured the use of besser bricks [1] for sheds.]
Regards, Nick.
[1] https://en.wikipedia.org/wiki/Concrete_masonry_unit
epel-devel@lists.fedoraproject.org
-
Bohuslav Kabrda -
Carl George -
Dan Callaghan -
David Malcolm -
Nick Coghlan -
Orion Poplawski -
Stephen John Smoogen