[HEADS-UP]: Mercurial with Python3 on rawhide?

[Petr Stodulka]

Hi guys,
as discussion was started week ago, Python2 is dying. As that, some
dependencies of mercurial will be orphaned soon (or they are already)
and mercurial as it is has to move in weeks on Python3. As I wrote
in [0], I already started some testing and investigation.

Currently it seems that with ugly hacky fix, we are able to run
somi-working mercurial with Python3. I did just simple testing
that worked for me and in the latest copr-build (below), it seems
that hgk extension is workin as well. But many of you extensions
will be probably broken. So, I guess the most probably mercurial
will be broken for the others who use it.

So it's question, should I rebase it in rawhide and setup for Python3
already even when it is so broken, or should I wait several weeks yet
for additional fixes?

If anyone is interested about testing before it will be done,
just try:
   # dnf copr enable pstodulk/mercurial
- it's just first attempt.

Here is the list of RPMs depending on mercurial:
git-cinnabar
gitifyhg
git-remote-hg
gwsmhg
hg-git
hgsvn
hgview-common
python2-anyvc
python2-wstool
python3-hgapi
python3-wstool
qct-mercurial
rabbitvcs-core
rbm
tortoisehg
trac-mercurial-plugin


Cheers,
Petr

[Zbigniew Jędrzejewski-Szmek]

On Tue, Aug 06, 2019 at 09:35:50PM +0200, Petr Stodulka wrote:
>  Hi guys,
>  as discussion was started week ago, Python2 is dying. As that, some
>  dependencies of mercurial will be orphaned soon (or they are already)
>  and mercurial as it is has to move in weeks on Python3. As I wrote
>  in [0], I already started some testing and investigation.
>  
>  Currently it seems that with ugly hacky fix, we are able to run
>  somi-working mercurial with Python3. I did just simple testing
>  that worked for me and in the latest copr-build (below), it seems
>  that hgk extension is workin as well. But many of you extensions
>  will be probably broken. So, I guess the most probably mercurial
>  will be broken for the others who use it.
>  
>  So it's question, should I rebase it in rawhide and setup for Python3
>  already even when it is so broken, or should I wait several weeks yet
>  for additional fixes? 
I think it's reasonable to ship in rawhide, if the basic clone
operations work. This will satisfy 99% of use cases, i.e. cloning
of repos from the web without any further interaction with the VCS.
I don't have any data to back this up, but since Mercurial has lost
a lot of it's erstwhile popularity, based on how things go with
other python2-only projects, chances are that most extensions will not
be updated in time for F31. And it's better to have somewhat functional
clone operation than nothing.

Zbyszek

[Miro Hrončok]

On 12. 08. 19 16:19, Zbigniew Jędrzejewski-Szmek wrote:
>  On Tue, Aug 06, 2019 at 09:35:50PM +0200, Petr Stodulka wrote:
> > Hi guys,
> > as discussion was started week ago, Python2 is dying. As that, some
> > dependencies of mercurial will be orphaned soon (or they are already)
> > and mercurial as it is has to move in weeks on Python3. As I wrote
> > in [0], I already started some testing and investigation.
> >
> > Currently it seems that with ugly hacky fix, we are able to run
> > somi-working mercurial with Python3. I did just simple testing
> > that worked for me and in the latest copr-build (below), it seems
> > that hgk extension is workin as well. But many of you extensions
> > will be probably broken. So, I guess the most probably mercurial
> > will be broken for the others who use it.
> >
> > So it's question, should I rebase it in rawhide and setup for Python3
> > already even when it is so broken, or should I wait several weeks yet
> > for additional fixes?
>  
>  I think it's reasonable to ship in rawhide, if the basic clone
>  operations work. This will satisfy 99% of use cases, i.e. cloning
>  of repos from the web without any further interaction with the VCS.
>  I don't have any data to back this up, but since Mercurial has lost
>  a lot of it's erstwhile popularity, based on how things go with
>  other python2-only projects, chances are that most extensions will not
>  be updated in time for F31. And it's better to have somewhat functional
>  clone operation than nothing. 
I suggest to switch after the branching in F32 only and than (re)consider doing 
a backport before the F31 beta freeze.

-- 
Miro Hrončok
--
Phone: [phone]
IRC: mhroncok

[Petr Stodulka]

On 12. 08. 19 16:33, Miro Hrončok wrote:
>  On 12. 08. 19 16:19, Zbigniew Jędrzejewski-Szmek wrote:
> > On Tue, Aug 06, 2019 at 09:35:50PM +0200, Petr Stodulka wrote:
> >> Hi guys,
> >> as discussion was started week ago, Python2 is dying. As that, some
> >> dependencies of mercurial will be orphaned soon (or they are already)
> >> and mercurial as it is has to move in weeks on Python3. As I wrote
> >> in [0], I already started some testing and investigation.
> >>
> >> Currently it seems that with ugly hacky fix, we are able to run
> >> somi-working mercurial with Python3. I did just simple testing
> >> that worked for me and in the latest copr-build (below), it seems
> >> that hgk extension is workin as well. But many of you extensions
> >> will be probably broken. So, I guess the most probably mercurial
> >> will be broken for the others who use it.
> >>
> >> So it's question, should I rebase it in rawhide and setup for Python3
> >> already even when it is so broken, or should I wait several weeks yet
> >> for additional fixes?
> >
> > I think it's reasonable to ship in rawhide, if the basic clone
> > operations work. This will satisfy 99% of use cases, i.e. cloning
> > of repos from the web without any further interaction with the VCS.
> > I don't have any data to back this up, but since Mercurial has lost
> > a lot of it's erstwhile popularity, based on how things go with
> > other python2-only projects, chances are that most extensions will not
> > be updated in time for F31. And it's better to have somewhat functional
> > clone operation than nothing.
>  
>  I suggest to switch after the branching in F32 only and than (re)consider doing a
> backport before the F31 beta freeze.
>   
Can you explain better what do you mean by that? I am little lost
here. Anyway, pointing out that Neal found python3 version for
him unusable and do not want to put it into rawhide.

There is suggestion about mercurial for python3 in subpackages.
I will prepare this week PoC for that, to provide at least some
way for users to have still working mercurial and provide the
benefit for developers to prepare for Python3.

I will send patch before I will do any changes in rawhide.

-- 
Petr Stodulka
OS & Application Modernization
IRC nicks: pstodulk, skytak
Software Engineer
Red Hat Czech s.r.o.

[Miro Hrončok]

On 12. 08. 19 20:37, Petr Stodulka wrote:
>  Can you explain better what do you mean by that? I am little lost
>  here. 
Sure. The idea was:

1) When Fedora 31 is branched (scheduled for tomorrow [1]), push the switch to 
rawhide (Fedora 32)

2) See what happens, collect feedback.

3) Soon before F31 Beta Freeze (scheduled for 2019-08-29 [1]) decide whether 
this is worth pushing to F31 (probably not)

4) Soon before F32 mass Python 2 removal flag day (scheduled for mid November 
[2]), decide whether to revert and request and exception or not

[1] https://fedoraproject.org/wiki/Releases/31/Schedule
[2] https://fedoraproject.org/wiki/Changes/RetirePython2#Detailed_Description

-- 
Miro Hrončok
--
Phone: [phone]
IRC: mhroncok

[Petr Stodulka]

On 12. 08. 19 22:36, Miro Hrončok wrote:
>  On 12. 08. 19 20:37, Petr Stodulka wrote:
> > Can you explain better what do you mean by that? I am little lost
> > here.
>  
>  Sure. The idea was:
>  
>  1) When Fedora 31 is branched (scheduled for tomorrow [1]), push the switch to rawhide
> (Fedora 32)
>  
>  2) See what happens, collect feedback.
>  
>  3) Soon before F31 Beta Freeze (scheduled for 2019-08-29 [1]) decide whether this is
> worth pushing to F31 (probably not)
>  
>  4) Soon before F32 mass Python 2 removal flag day (scheduled for mid November [2]),
> decide whether to revert and request and exception or not
>  
>  [1] https://fedoraproject.org/wiki/Releases/31/Schedule
>  [2] https://fedoraproject.org/wiki/Changes/RetirePython2#Detailed_Description
>   
Thanks Miro for explanation. That sounds asi the best idea now probably. From that point,
I will not create new subpackages for Py2 / Py3 and I will just do the switch tomorrow.

@mercurial-maintainers: if anyone have something against or better solution, answer here
guys, otherwise I will do the rebase.
Just FYI, I will be kinda offline between 2019-08-15 - 2019-08-25 because of PTO. So in
case of troubles, I will not be able to do anything during that time. From that point, I
could postpone the rebase if needed, but I hope that someone else will be able to help
around instead of me in case of troubles.

-- 
Petr Stodulka
OS & Application Modernization
IRC nicks: pstodulk, skytak
Software Engineer
Red Hat Czech s.r.o.

[Neal Becker]

I just tested hg-5.1.0 with the latest git version of hg-evolve on
python3 and at least some basic things seem to be working.  One
problem:
hg
*** failed to import extension hggit: No module named 'compat'

That's with the latest pip version of hg-git (0.8.12).

hg-git is a supported fedora package, so I think we need this to work.

On Tue, Aug 13, 2019 at 9:35 AM Petr Stodulka <pstodulk(a)redhat.com&gt; wrote:
>  On 12. 08. 19 22:36, Miro Hrončok wrote:
>  > On 12. 08. 19 20:37, Petr Stodulka wrote:
>  >> Can you explain better what do you mean by that? I am little lost
>  >> here.
>  >
>  > Sure. The idea was:
>  >
>  > 1) When Fedora 31 is branched (scheduled for tomorrow [1]), push the switch to
> rawhide (Fedora 32)
>  >
>  > 2) See what happens, collect feedback.
>  >
>  > 3) Soon before F31 Beta Freeze (scheduled for 2019-08-29 [1]) decide whether this is
> worth pushing to F31 (probably not)
>  >
>  > 4) Soon before F32 mass Python 2 removal flag day (scheduled for mid November [2]),
> decide whether to revert and request and exception or not
>  >
>  > [1] https://fedoraproject.org/wiki/Releases/31/Schedule
>  > [2] https://fedoraproject.org/wiki/Changes/RetirePython2#Detailed_Description
>  >
>
>  Thanks Miro for explanation. That sounds asi the best idea now probably. From that point,
> I will not create new subpackages for Py2 / Py3 and I will just do the switch tomorrow.
>
>  @mercurial-maintainers: if anyone have something against or better solution, answer here
> guys, otherwise I will do the rebase.
>  Just FYI, I will be kinda offline between 2019-08-15 - 2019-08-25 because of PTO. So in
> case of troubles, I will not be able to do anything during that time. From that point, I
> could postpone the rebase if needed, but I hope that someone else will be able to help
> around instead of me in case of troubles.
>
>  --
>  Petr Stodulka
>  OS & Application Modernization
>  IRC nicks: pstodulk, skytak
>  Software Engineer
>  Red Hat Czech s.r.o. 


-- 
Those who don't understand recursion are doomed to repeat it

[Neal Becker]

I think tortoisehg is not ported to python3

On Wed, Aug 14, 2019 at 1:39 PM Neal Becker <ndbecker2(a)gmail.com&gt; wrote:
>  I just tested hg-5.1.0 with the latest git version of hg-evolve on
>  python3 and at least some basic things seem to be working.  One
>  problem:
>  hg
>  *** failed to import extension hggit: No module named 'compat'
>
>  That's with the latest pip version of hg-git (0.8.12).
>
>  hg-git is a supported fedora package, so I think we need this to work.
>
>  On Tue, Aug 13, 2019 at 9:35 AM Petr Stodulka <pstodulk(a)redhat.com&gt; wrote:
>  >
>  >
>  >
>  > On 12. 08. 19 22:36, Miro Hrončok wrote:
>  > > On 12. 08. 19 20:37, Petr Stodulka wrote:
>  > >> Can you explain better what do you mean by that? I am little lost
>  > >> here.
>  > >
>  > > Sure. The idea was:
>  > >
>  > > 1) When Fedora 31 is branched (scheduled for tomorrow [1]), push the switch to
> rawhide (Fedora 32)
>  > >
>  > > 2) See what happens, collect feedback.
>  > >
>  > > 3) Soon before F31 Beta Freeze (scheduled for 2019-08-29 [1]) decide whether
> this is worth pushing to F31 (probably not)
>  > >
>  > > 4) Soon before F32 mass Python 2 removal flag day (scheduled for mid November
> [2]), decide whether to revert and request and exception or not
>  > >
>  > > [1] https://fedoraproject.org/wiki/Releases/31/Schedule
>  > > [2] https://fedoraproject.org/wiki/Changes/RetirePython2#Detailed_Description
>  > >
>  >
>  > Thanks Miro for explanation. That sounds asi the best idea now probably. From that
> point, I will not create new subpackages for Py2 / Py3 and I will just do the switch
> tomorrow.
>  >
>  > @mercurial-maintainers: if anyone have something against or better solution, answer
> here guys, otherwise I will do the rebase.
>  > Just FYI, I will be kinda offline between 2019-08-15 - 2019-08-25 because of PTO. So
> in case of troubles, I will not be able to do anything during that time. From that point,
> I could postpone the rebase if needed, but I hope that someone else will be able to help
> around instead of me in case of troubles.
>  >
>  > --
>  > Petr Stodulka
>  > OS & Application Modernization
>  > IRC nicks: pstodulk, skytak
>  > Software Engineer
>  > Red Hat Czech s.r.o.
>
>
>
>  --
>  Those who don't understand recursion are doomed to repeat it 


-- 
Those who don't understand recursion are doomed to repeat it

[Georges Racinet]

Hi,

I think this particular compatibility issue has been fixed in hg-git default branch, so
you might wanna retry on it.
For the record, I just tested very quickly Mercurial 5.1 with hg-git in a Python3
virtualenv and it seems to work.