bpls Precedence over ADIOS1 about adios2-feedstock HOT 8 CLOSED

That be a non-canonical break the API of the package for anyone still using adios1. You can't control when downstream users choose to stop using adios1.

from adios2-feedstock.

My suggestion is that you split the adios recipe like the adios2 recipe is split, so there would be four packages: adios, libadios, adios2, libadios2. Then make adios2 and adios mutually exclusive using run_constrained. i.e.

# In the adios2 recipe
requirements:
  run_constrained:
    - adios =999999  # impossible to satisfy, so adios and adios2 cannot be co-installed.

# In the adios recipe
requirements:
  run_constrained:
    - adios2 =999999  # impossible to satisfy, so adios and adios2 cannot be co-installed.

This would probably allow the following valid environments:

• adios, libadios, libadios2
• adios2, libadios, libadios2

But the following would not be allowed:

• adios, adios2, ...

Conda doesn't support the concept that two packages supply the same tool and that one should take precedence over the other. In order to accomplish something like that, bpls would need to be published from its own feedstock.

If the maintainers of adios2 wanted their tools to be co-installable with the old ones, they should/would have renamed thier tools to something like bpls2.

from adios2-feedstock.

Thank you for the guidance!

I have to admit that splitting of the package is not my forte and was contributed by @minrk .

What do you think about this solution? I would rename bpls in ADIOS1 to bp3ls (for BP3 fils it can read) and fix the problem like this? That would be fast, user-understandable and only changes the legacy package that we can in the mid-term remove once dependents drop it.
conda-forge/adios-feedstock#35

from adios2-feedstock.

Since ADIOS1 is EOL, I think that is ok. Also, ADIOS2 bpls can read its data. I am really transitioning out here, years after the main devs stopped supporting it. From what I know from the developer community, depends also moved to ADIOS2 already.

from adios2-feedstock.

If adios1 is EOL, then don't use it in any of your packages and you won't have any collision problems?

from adios2-feedstock.

Only around for the C lib that reads legacy files, removed in the next major release.

from adios2-feedstock.

We can add a run_constrained to prevent them being in the same env, to make the conflict explicit. Would that be desirable?

from adios2-feedstock.

No, I really want them in the same env.

It's really no problem, I am probably the only left read-only user of ADIOS1 and renaming that CLI to bp3ls fixes the long-standing issue that it took precedence over ADIOS2's, which can read both.

from adios2-feedstock.