Port variants for deps

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Port variants for deps

Eric F (iEFdev)

Evening all,

To pass along a variant for a dependency, without having to add in when you install.
How do you do that? …or is there really no other way than adding it during “port install”.

One would like to do:
```
depends_lib.append	port:first \
			port:second +foo_bar \
			port:third
```

// That doesn't work, but as a visual for the question.

I tried adding an extra variant with the same name and set to default, but no luck.

Any ideas? or is it just not possible?

 · Eric

Reply | Threaded
Open this post in threaded view
|

Re: Port variants for deps

Joshua Root-8
On 2019-9-16 12:44 , Eric F (iEFdev) wrote:

> /Evening all,/
>
> To pass along a variant for a dependency, without having to add in when
> you install.
> How do you do that? …or is there really no other way than adding it
> during “port install”.
>
> One /would/ like to do:
>
> ```
> depends_lib.append port:first \
> port:second +foo_bar \
> port:third
> ```
>
> // That doesn't work, but as a visual for the question.
>
> I tried adding an extra variant with the same name and set to default,
> but no luck.
>
> Any ideas? or is it just not possible?

<https://trac.macports.org/ticket/126>
Reply | Threaded
Open this post in threaded view
|

Re: Port variants for deps

Eric F (iEFdev)

Thanks Joshua!

That was one old (and long-lived) ticket. :)

Yes, it would be better if the dep had subports.

What would be better (ie good “portiqette”)… Adding subports (keeping the variants), or replacing variants with subports?

 · Eric



On 9/16/19 4:55 , Joshua Root wrote:
On 2019-9-16 12:44 , Eric F (iEFdev) wrote:
/Evening all,/

To pass along a variant for a dependency, without having to add in when
you install.
How do you do that? …or is there really no other way than adding it
during “port install”.

One /would/ like to do:

```
depends_lib.append	port:first \
			port:second +foo_bar \
			port:third
```

// That doesn't work, but as a visual for the question.

I tried adding an extra variant with the same name and set to default,
but no luck.

Any ideas? or is it just not possible?
<https://trac.macports.org/ticket/126>
Reply | Threaded
Open this post in threaded view
|

Re: Port variants for deps

ryandesign2
Administrator


On Sep 15, 2019, at 22:31, Eric F (iEFdev) wrote:

> What would be better (ie good “portiqette”)… Adding subports (keeping the variants), or replacing variants with subports?

Provide only one way for a user to install a feature. Convert variants to subports, if appropriate.

Usually if a variant changes names we keep a compatibility variant around for a time. For example, if a port provided a variant X which a user may have installed, and then we change the variant name to Y, we keep a variant X that's marked as requiring variant Y. When the user upgrades their installation, they will automatically get the new variant Y (and the old variant X which now does nothing). After a sufficient period of time to allow all users to have upgraded (we usually recommend one year), the old variant X can be removed.

Converting variants to subports may or may not allow that same easy upgrade path to take place. For example, if the new subport has a dependency on the main port, you cannot make the old variant depend on the new subport, because that would introduce a circular dependency. One possibility in that case is to leave a compatibility variant for a time that does nothing but print an error message telling the user to install the subport.

Reply | Threaded
Open this post in threaded view
|

Re: Port variants for deps

Eric F (iEFdev)
On 9/16/19 23:20 , Ryan Schmidt wrote:
On Sep 15, 2019, at 22:31, Eric F (iEFdev) wrote:
What would be better (ie good “portiquette”)… Adding subports (keeping the variants), or replacing variants with subports?
Provide only one way for a user to install a feature. Convert variants to subports, if appropriate.
Thanks Ryan! Yes, I guess that's the best way, and cleaner.

Usually if a variant changes names we keep a compatibility variant around for a time. For example, if a port provided a variant X which a user may have installed, and then we change the variant name to Y, we keep a variant X that's marked as requiring variant Y. When the user upgrades their installation, they will automatically get the new variant Y (and the old variant X which now does nothing). After a sufficient period of time to allow all users to have upgraded (we usually recommend one year), the old variant X can be removed.

Converting variants to subports may or may not allow that same easy upgrade path to take place. For example, if the new subport has a dependency on the main port, you cannot make the old variant depend on the new subport, because that would introduce a circular dependency. One possibility in that case is to leave a compatibility variant for a time that does nothing but print an error message telling the user to install the subport.
I made a PR yesterday »», and that was what I had i mind. It will work both ways - as subports, but still be able to use it the same way as before (didn't want to break anything). And if the variants have to go (later), one could put everything in a switch later, or something like that.

If that approach is ok, perhaps I should add an err-msg like that to it? Err, or note?

· Eric
Reply | Threaded
Open this post in threaded view
|

Re: Port variants for deps

ryandesign2
Administrator


On Sep 16, 2019, at 17:01, Eric F (iEFdev) wrote:

> On 9/16/19 23:20 , Ryan Schmidt wrote:
>> On Sep 15, 2019, at 22:31, Eric F (iEFdev) wrote:
>>
>>> What would be better (ie good “portiquette”)… Adding subports (keeping the variants), or replacing variants with subports?
>>>
>> Provide only one way for a user to install a feature. Convert variants to subports, if appropriate.
>>
> Thanks Ryan! Yes, I guess that's the best way, and cleaner.
>
>> Usually if a variant changes names we keep a compatibility variant around for a time. For example, if a port provided a variant X which a user may have installed, and then we change the variant name to Y, we keep a variant X that's marked as requiring variant Y. When the user upgrades their installation, they will automatically get the new variant Y (and the old variant X which now does nothing). After a sufficient period of time to allow all users to have upgraded (we usually recommend one year), the old variant X can be removed.
>>
>> Converting variants to subports may or may not allow that same easy upgrade path to take place. For example, if the new subport has a dependency on the main port, you cannot make the old variant depend on the new subport, because that would introduce a circular dependency. One possibility in that case is to leave a compatibility variant for a time that does nothing but print an error message telling the user to install the subport.
>>
> I made a PR yesterday »», and that was what I had i mind. It will work both ways - as subports, but still be able to use it the same way as before (didn't want to break anything). And if the variants have to go (later), one could put everything in a switch later, or something like that.
>
> If that approach is ok, perhaps I should add an err-msg like that to it? Err, or note?


Oh, I didn't realize you were talking about a perl module. That's more complicated, because a perl module port already creates its own subports, one for each perl version. I see you've figured out a way to do it anyway, but I'm really not sure it's advisable. There are other ports that depend on p5-dbd-mysql. What do you expect them to do? Do you expect each and every one of them to add variants for each version of mysql/mariadb, and in those variants choose the matching new subport of p5-dbd-mysql?

In the case of ports that use mysql/mariadb, the idea was that the user should be in control of what version of mysql/mariadb is used. The user can specify their choice globally in variants.conf and then it applies to any port offering those variants. It should not be up to other ports to make that decision for the user.

And you've noticed that each of your proposed subports would conflict with each other. Subports aren't supposed to conflict. They're supposed to be installable at the same time, because they're supposed to represent things a user might want to install at the same time. That doesn't fit this scenario, where variants are probably the best solution, as Dave mentioned in the PR when he closed it.

Subports are great for optional features that can be built later. For example, optional documentation for a program -- a user doesn't want to have to recompile the program just to install its documentation. Or consider graphviz: it has a main port for the command line programs and libraries, and subports for the optional macOS and Qt GUIs. Or nginx: its many variants should be converted to subports so that those modules can be built each by themselves when they're needed without having to recompile nginx itself. (My understanding is that Clemens wanted to do this but that nginx's plugin/module support wasn't yet good enough to do it, or maybe the various plugins/modules hadn't adapted to the new way to do it, but that was a few years ago so maybe the situation has improved since then and the conversion to subports could now be done.) The php port's many subports are another (way too complicated) example.

Reply | Threaded
Open this post in threaded view
|

Re: Port variants for deps

Eric F (iEFdev)
On 9/20/19 3:10 , Ryan Schmidt wrote:
Oh, I didn't realize you were talking about a perl module. That's more complicated, because a perl module port already creates its own subports, one for each perl version. I see you've figured out a way to do it anyway, but I'm really not sure it's advisable.
I wanted to see how the Perl subports were made, so I looked int the portgroup and found a usable function to work with. No, prob not the best way, more than it worked. (Since the perl2{6,8} are subports already - technicallly, they became: “sub-subports”. :))

There are other ports that depend on p5-dbd-mysql. What do you expect them to do? Do you expect each and every one of them to add variants for each version of mysql/mariadb, and in those variants choose the matching new subport of p5-dbd-mysql?

In the case of ports that use mysql/mariadb, the idea was that the user should be in control of what version of mysql/mariadb is used. The user can specify their choice globally in variants.conf and then it applies to any port offering those variants. It should not be up to other ports to make that decision for the user.
> “What do you expect them to do?”

Well, here's the idea I had (still have)...

MariaDB ships with a newer/better version of “mytop” (»»», 2012), compared to the standard mytop (»»», from 2002). Quite a lot of changes and improvements.
Since it's comes bundled with the mariadb install, I thought it would be nice to make it work out of the box. It wouldn't take much to do it:
 - Reinplace the “shebang”,
 - add a sample config file,
 - and add 2 dependencies (to get the 3).

But, since things are as they are now. If that was added, one would need to install (example) mariadb-10.2 with: `port install mariadb-10.2 +mariadb10_2` - which doesn't feel ok (or look good), for something that was supposed to work out of the box. That's why I wanted to have the dependecy picking up the variant automatically. It would be really nice to make it work right away.

I guess I could make a port that is fixing that instead - were ppl have to choose a specific variant (and/or with the help of that variant port group Dave mentioned). Or make a “mariatop” separately, to avoid name confilicts. I don't know. I'm still bouncing the ideas. But, that was the idea.

And you've noticed that each of your proposed subports would conflict with each other. Subports aren't supposed to conflict. They're supposed to be installable at the same time, because they're supposed to represent things a user might want to install at the same time. That doesn't fit this scenario, where variants are probably the best solution, as Dave mentioned in the PR when he closed it.
Yes, I understand that, and why it got closed. But, even though the name/term is “subport”, they were kind of not subports… They were more acting as a “translation layer”, and not real ports - just matching the variant. Anyway, I thought it was a smart simple way, with minimal xtra code added to solve it.

To go back to earlier discussion… Even if the PR was closed (and I don't expect it to get reopened again), I finished it with an example of separate (sub-)subports and variands. Just wanted to finish it, exapand the idea, and see where [the code] took me. »»» (I'll remove that one later).

Not too much xtra code, but it'll get cluttered …and then all those conflicts, that are not supposed to conflict. :) But, that was based on that about making subports, and remove the variant later on.


I'll look into the other ideas instead - or, any suggestions…?

 · Eric