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> -----
On Fri, May 21, 2021 at 9:53 AM David A Case <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 - 05:30:02 PDT
