search

conda-forge / epics-base-feedstock

A conda-smithy repository for epics-base.
BSD 3-Clause "New" or "Revised" License
0 stars 6 forks source link

EPICS_HOST_ARCH and other environment variables can override system-defined settings #15

Closed klauer closed 2 years ago

klauer commented 2 years ago

Issue

Settings in the activation script such as this: https://github.com/conda-forge/epics-base-feedstock/blob/1084f602acb591c807347ffe4adf78ac5a33125f/recipe/build.sh#L50 Can override the existing environment's settings undesirably.

Example

Specifically, at the LCLS we have a custom EPICS_HOST_ARCH defined for our machines that depends on the RedHat release version. That is, we have rhel6-x86_64, and rhel7-x86_64 whereas upstream epics-base only defines linux-x86_64.

(ours) https://github.com/slac-epics/epics-base/blob/091367acbd3112bb2a6fc8397e0e5b1006d79d70/startup/EpicsHostArch.pl#L35-L36 (theirs) https://github.com/epics-base/epics-base/blob/3e371da8ec327509621845c8c4a67c1e9cb61462/src/tools/EpicsHostArch.pl#L35

Such an activation script can then break the existing environment where rhel7-x86_64 is not equivalent to the feedstock-defined linux-x86_64.

Workaround?

A few possible workarounds that come to mind are the following:

  1. Could the activation script look for a flag that enables/disables the current functionality?
  2. Could the activation script only set variables that were previously unset?

Alternatively, is there a mechanism in conda for disabling specific activation scripts that we might be unaware of?

cc @zllentz @tangkong

beenje commented 2 years ago

Hello, As far as I know there is no mechanism to disable activation scripts. I'm not sure to understand the use case.

The goal of conda is to create binary packages that are independent of the OS. This package should allow to install epics-base on Debian or CentOS (not sure if rhel6 is supported, but for sure rhel7 or rhel8 should work), so using the default linux-x86_64 makes sense. Libraries will be installed under <conda env>/epics/lib/linux-x86_64. Changing the EPICS_HOST_ARCH will probably break things.

If you want to use this conda epics-base package, you should compile everything using it. You shouldn't try to mix it with another environment / different epics-base. Either you use the conda-forge epics-base and compile your IOC with it, either you use your own epics-base. Both environment can coexist on the same machine. The conda one will only set the proper variables when activated. If we don't some things might probably break for this environment.

Or did I misunderstand the issue?

klauer commented 2 years ago

If you want to use this conda epics-base package, you should compile everything using it.

I'm afraid that's not a possibility for us. We have thousands of IOCs and support modules on epics-base versions from 3-14 to 7 on various architectures unsupported by your distribution.

Is everything EPICS built with conda at your facility? I would be interested to see how you have it set up.

You shouldn't try to mix it with another environment / different epics-base.

We do not specifically want to use your package, but rather we are forced to use it because it is a hard dependency of other Python packages present in our environment (regardless of if we use those parts or not).

The summary is that sourcing an environment with the provided activation script breaks other tools we have that expect the correct (to us) host architecture environment variable. We were hoping for a mutually agreeable mechanism to allow disabling the activation script for this package, but I see that your view of how this package must be used will not allow for that.

Thanks for your time.

beenje commented 2 years ago

Is everything EPICS built with conda at your facility? I would be interested to see how you have it set up.

I did some experiment when working at ESS but this isn't the solution that was chosen. I don't work there anymore, so I don't know the current status. You can find some (old?) documentation and some links here:

You shouldn't try to mix it with another environment / different epics-base.

We do not specifically want to use your package, but rather we are forced to use it because it is a hard dependency of other Python packages present in our environment (regardless of if we use those parts or not). The summary is that sourcing an environment with the provided activation script breaks other tools we have that expect the correct (to us) host architecture environment variable. We were hoping for a mutually agreeable mechanism to allow disabling the activation script for this package, but I see that your view of how this package must be used will not allow for that.

Thanks for your time.

OK, I understand. That's tricky. Not sure I have a good solution. Maybe patching the conda package on your side is an option? Or you could maybe create your own conda package that overwrites those variables?

andersharrisson-ess commented 2 years ago

I did some experiment when working at ESS but this isn't the solution that was chosen. I don't work there anymore, so I don't know the current status.

To shed some light on the current ESS implementation: It is true that a majority of the IOCs at ESS are deployed by other means, but we do also have (and intend to keep having) IOCs deployed using Conda. Our IOCs deployed with Conda are intended to be distribution agnostic and do not rely on system dependencies. We maintain our own recipe for epics-base (https://gitlab.esss.lu.se/e3-recipes/epics-base-recipe/) as well as all modules needed and the packages are distributed through our internal Conda channel(s), i.e. we're not using conda-forge directly.

I share @beenje 's view, that it should be considered discouraged to mix environments since it's a recipe (pun?) for problems. @klauer, I'm afraid I don't have any better ideas to solve your issues than what's already been mentioned.