Is there an alternative to variants for variable requirements?

[herronelou]

Hi.

In order to keep code python 2/3 compatibles, I've had to install a few backported tool (for example enum34, and future-fstrings).

enum34 is required for python<3.4, future-fstrings for python<3.6.

My package itself is pure python.

I can use variants:

variants = [
    ['python-3.6+'],
    ['python-3.4+<3.6', 'future_fstrings'],
    ['python-<3.4', 'future_fstrings', 'enum34']
]

It's a bit verbose, and if more backported libraries are added, which were all added at different python versions, the list grows and grows.

I was hoping to do something like:

@late()
def requires():
    requirements = ['python']
    if in_context():
        if intersects(request.get_range('python'), '<3.6':
            requirements.append('future_fstrings')
        if intersects(request.get_range('python'), '<3.4':
            requirements.append('enum34')
    return requirements

This almost works, but only if my python request is precise. If the python request was just 'python', it would solve to the latest python, but add both extra packages. This is also quite verbose, but this way I'm not making a bunch of copies of my code for no reasons (the variants have no difference, apart rom their requirements).

Is there a better way of doing this?

Edit:
On top of that, I just noticed that with variants, if I do rez-env my_package it picks python 2.7 by default, whereas rez-env python or rez-env my_package python-3 picks python-3.7.9.

[nerdvegas]

I would avoid late requires personally. Nothing to do with your specific issue, I'm just uneasy about late binding in general. Also though, this isn't going to necessarily work - iirc the `request` object in this context is the initial request, but there's no guarantee that python was explicitly requested in the first place. Python version could be determined indirectly by the python requirement of another package in the solve. Doing it with variants is the way to go.

…

On Wed, Apr 20, 2022 at 10:53 AM Erwan Leroy ***@***.***> wrote: Hi. In order to keep code python 2/3 compatibles, I've had to install a few backported tool (for example enum34, and future-fstrings). enum34 is required for python<3.4, future-fstrings for python<3.6. My package itself is pure python. I can use variants: variants = [ ['python-3.6+'], ['python-3.4+<3.6', 'future_fstrings'], ['python-<3.4', 'future_fstrings', 'enum34'] ] It's a bit verbose, and if more backported libraries are added, which were all added at different python versions, the list grows and grows. I was hoping to do something like: @late() def requires(): requirements = ['python'] if in_context(): if intersects(request.get_range('python'), '<3.6': requirements.append('future_fstrings') if intersects(request.get_range('python'), '<3.4': requirements.append('enum34') return requirements This almost works, but only if my python request is precise. If the python request was just 'python', it would solve to the latest python, but add both extra packages. This is also quite verbose, but this way I'm not making a bunch of copies of my code for no reasons (the variants have no difference, apart rom their requirements). Is there a better way of doing this? — Reply to this email directly, view it on GitHub <#1290>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAMOUSSD3UCRUJVUDACMRELVF5IPHANCNFSM5T2OXF3Q> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[herronelou]

That seems consistent with my observations.

One thing I thought about since posting is that I could make an "intermediate" package, call it for example "py3backports" and setup all the variants there. Since that package itself would have no payload, it would not create any unnecessary variant payloads and all I would need is add this package as a require?
Is that an ok pattern or is it better to set the variants directly in each package?