It is intended for both py2 and py3 packages to be parallel installed, correct?

On Mon, Aug 26, 2019, 1:52 PM Petr Stodulka <pstodulk@redhat.com> wrote:
Hi guys,
I already spent some time on that and I have resolved majority of problems
with split. The blocker for now - which I believe it is possible to resolve
but I haven't found a solution yet - are libexec files - I need to install
filse for py3 into mercurial3 (or in different dir in general) and use those
when using hg3.

Unfortunately, to be able to create everything under one specfile, I had to
create /usr/bin/hg for py2 and /usr/bin/hg3 for py3. In case the hg is required
in both cases, we have to create new component in fedora, otherwise there is
no way to resolve it.

I have very limited time between my two holidays, but I will try to do another
progress and at least attach my latest solution to the BZ so someone can continue
instead of start from the scratch again.

Petr

On 20. 08. 19 19:54, Neal Becker wrote:
> I agree that subpackages for py2 and py3 seems best, but I'll have to
> see if mercurial can be parallel installed without too much effort.
> I don't expect to have time to work on this for the next 2 weeks.
>
> On Sun, Aug 18, 2019 at 9:16 PM Mads Kiilerich <mads@kiilerich.com> wrote:
>>
>> You are giving many good reasons why we need Mercurial packages for
>> Python 2 and Python 3, side by side.
>>
>> That will make it possible for other packages to jump to Python 3. Your
>> package will no longer be blocking, and it doesn't have to be your concern.
>>
>> It will also put the Mercurial package in the good position where it has
>> done all the work of transitioning, and the python2 part will be
>> entirely optional, only kept alive for benefit of other packages that
>> still depend on it.
>>
>> I am working upstream with tortoisehg. While late, I don't expect any
>> problems. The current blocker for Fedora packaging of tortoisehg is the
>> lack of Python 3 Mercurial, and the biggest risk is that the Python 2
>> Mercurial package goes away before I had time to transition the
>> tortoisehg package to depend on Python 3 Mercurial.
>>
>> /Mads
>>
>>
>>
>> On 8/16/19 3:53 PM, Neal Becker wrote:
>>> I think tortoisehg is not ported to python3
>>>
>>> On Wed, Aug 14, 2019 at 1:39 PM Neal Becker <ndbecker2@gmail.com> 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@redhat.com> 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
>>>
>>>
>>
>
>

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