Poll about optional package behaviour

[Dag Sverre Seljebotn]

Poll about optional packages:

Assume the profile

packages:
a: # deps: [a, c?, x?]
b: # deps: [x, y?]
c:

The following is already decided:
- b.x is required, so x will be auto-included in the profile and passed
to the build of b
- a.c is optional, but c is specified in profile and is therefore passed
to the build of a

However, does the hard dependency on x by b, cause x to also be passed
to the build of a?

Option 1: a.x is passed x because it is required for b.x
Pro: x is built anyway, might as well make use of it

Option 2: a.x is None even if x is built to be passed as b.x
Pro: Tacking on b at bottom of packages list doesn't cause a to
suddenly be gratuitously rebuilt.

Note that as we get constraint solving, then of course adding a new
package can cause previous packages to suddenly need upgrades etc.
anyway, so this is not something we can avoid in general.

Which behaviour is least surprising? I am really torn here.

All of this is overridable anyway by being more explicit: Disable case:

a:
x: null
...

Enable case:

a:
x:



Dag Sverre

[Francois Bissey]

I am a Gentoo-er so to me everything is as configurable as possible and
this is not very different from optional dependency by use flag in Gentoo.

By default _I_ wouldn’t build a.x, if it is configurable it has to be explicitly
configured. So option 2 for me.

I certainly would want to be able to over-ride things if option1 was the
default. a.x could have undesirable behaviour as far as I am concerned.

François

> --
> You received this message because you are subscribed to the Google Groups "hashdist" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to hashdist+u...@googlegroups.com.
> To post to this group, send email to hash...@googlegroups.com.
> Visit this group at http://groups.google.com/group/hashdist.
> To view this discussion on the web visit https://groups.google.com/d/msgid/hashdist/555DB1AB.50705%40astro.uio.no.
> For more options, visit https://groups.google.com/d/optout.

[Dag Sverre Seljebotn]

Hmm, I guessing then you think that in the example, even a.c should be
None?, i.e., that it doesn't help to put it into the packages: list, it
needs to be explicitly passed?

In which case you need to do this:

packages:
a:
c: c
c: # <- presence of this here irrelevant to a

I kind of like that too, often explicit is better than implicit. How do
people feel about it? And down the road, to which degree will constraint
solving be used to select whether to pass optional dependencies or not?

The best real-world example is petsc of course.

Dag Sverre

[Francois Bissey]

> On 21/05/2015, at 22:35, Dag Sverre Seljebotn <d.s.se...@astro.uio.no> wrote:
>
> Hmm, I guessing then you think that in the example, even a.c should be None?, i.e., that it doesn't help to put it into the packages: list, it needs to be explicitly passed?
>

Yes. I don’t see why it would be different from a.x. Either you get both or none.
It has to be consistent.

François

[Chris Kees]

I'll be the devil's advocate: Option 1, with "a?" interpreted as "Is 'a' available? If yes, then use it to meet the optional  dependency". 

Since you can explicitly override it, then the case when you want to create a profile with a.x==None is fully supported, but I  suspect that case will be infrequent.  I think more commonly we will have something like libpng where a bunch of packages have it as an optional dependency, and option 2 will force us to  explicitly include it in the profile, which would make for longer  profiles, albeit not that much longer. 

Option 2 seems like the effect will be to force profile writers to think about the  low-level libraries needed to get  the high-level packages  they want.  Maybe you could fix this with another bit of syntax like a! = "Specify 'a' if  you want  to  use it to meet the optional dependency!". 

--
You received this message because you are subscribed to the Google Groups "hashdist" group.
To unsubscribe from this group and stop receiving emails from it, send an email to hashdist+u...@googlegroups.com.
To post to this group, send email to hash...@googlegroups.com.
Visit this group at http://groups.google.com/group/hashdist.

To view this discussion on the web visit https://groups.google.com/d/msgid/hashdist/8429E63C-EEB9-4CCA-814D-1CF1CE0BC2A4%40canterbury.ac.nz.

[Dag Sverre Seljebotn]

On 05/21/2015 05:11 PM, Chris Kees wrote:
> I'll be the devil's advocate: Option 1, with "a?" interpreted as "Is 'a'
> available? If yes, then use it to meet the optional dependency".
>
> Since you can explicitly override it, then the case when you want to
> create a profile with a.x==None is fully supported, but I suspect that
> case will be infrequent. I think more commonly we will have something
> like libpng where a bunch of packages have it as an optional dependency,
> and option 2 will force us to explicitly include it in the profile,
> which would make for longer profiles, albeit not that much longer.
>
> Option 2 seems like the effect will be to force profile writers to think
> about the low-level libraries needed to get the high-level packages
> they want. Maybe you could fix this with another bit of syntax like a!
> = "Specify 'a' if you want to use it to meet the optional dependency!".

Or "a?!?" :D

I think these are good arguments, if nobody else chimes in this is what
I'll do.

Dag Sverre

[Francois Bissey]

It is a valid point of view. It just depends on what default behaviour you
want to provide.
Explicit enable/implicit disable
Explicit disable/implicit enable

Either will force you to think when you want something that is not
default. It is all about the balance you want to achieve.
But it must be clear in the documentation what the expected
behaviour should be.

François

> To view this discussion on the web visit https://groups.google.com/d/msgid/hashdist/CAOVFbFiPXhHUBWNsUssD0TsV8cpC5v81Hsn1kTF8_Ttqr4GLag%40mail.gmail.com.