Dear Prof. Case,
many thanks for getting the response from Jason.
In my view, the trouble with the current situation is that essentially now it is not possible have dependencies on AmberTools in other conda packages without severe limitations and need for out of book recipes.
Previously, we could request AmberTools to be installed as requirements for a package and get AmberTools registered, hence fulfilling the runtime requirements put on a primary package by conda, enabling us, for example, to import pytraj and to run the package.
Now, if we have dependency on AmberTools it will still install correctly but since AmberTools is not registered as module anymore the primary package will fail to execute. And since there seems not to be any AmberUtils conda package, we cannot set dependency for it instead. So, either we can install but not run the package, or we cannot install automatically but we can run.
It is also quite possible that I am still missing some relevant aspect of conda management that would let a package to depend on AmberTools meta-package during installation but check for the availability of the adequate version of AmberUtils during its execution.
Best wishes,
Jan
On 22-May-21 2:08 PM, David A Case wrote:
janbre.amu.edu.pl<mailto:janbre.amu.edu.pl> asked:
How should downstream users import AmberTools?
Sorry for the slow reply here. I didn't get this question to the right
person earlier. It actually doesn't have much to do with the conda package
per se.
See the response from Jason Swails below.
...thanks...dac
----- Forwarded message from Jason Swails <jason.swails.gmail.com><mailto:jason.swails.gmail.com> -----
On Fri, May 21, 2021 at 9:53 AM David A Case <david.case.rutgers.edu><mailto:david.case.rutgers.edu> wrote:
Hi Jason: I think the user below is referring to the renaming of
"ambertools" (an internal package you used to make) to "AmberUtils". I
vaguely remember talking about doing this to reduce confusion or name
collisions with the full AmberTools package.
The old "ambertools" package was actually just the collection of all Python
utilities in AmberTools/src/etc/ (that was something I added long before we
played with conda). It looks like some packages used the presence of that
package as a proxy for the availability of the entirety of the AmberTools
suite.
Moving forward, we can either:
* Reverse that decision and re-publish an AmberTools package
* Tell packages to start depending on AmberUtils instead
I'd probably opt for the latter.
Of course, I may be completely off base, but can you see enough info below
to help the user? How should downstream users import AmberTools?
I think the problem is for downstream software developers that want to
release packages that rely on AmberTools. They have to declare that Amber
be installed as a package requirement (I think), so they should simply look
for AmberUtils instead of AmberTools.
----- End forwarded message -----
_______________________________________________
AMBER mailing list
AMBER.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber
Received on Sat May 22 2021 - 08:30:02 PDT
