>
> We plan on following Cargo fairly closely, seeing as they have the most
> robust new community out there. However we don¹t plan on managing C and
> C++ libraries in the first release, rather we are looking to delegate that
> to another manager in the future. We¹re considering Nix, but would
> appreciate your input if you have another suggestion.
>
One suggestion towards helping with external dependencies (not necessarily
managing them) would be for Mason packages to provide information on the
recommended Debian or RPM packages that could satisfy the dependence. For
example, the Debian package for GMP isn't "libgmp"; it's "libgmp10".
Similarly, ZeroMQ has separate Debian packages for each of the {2,3,4}.x
source versions, but the package names do not intuitively correspond; i.e.,
2.x -> libzmq1, 3.x -> libzmq3, 4.x -> libzmq5. Chapel will also typically
need the developer packages as well to #include C headers. I think that
providing all this information, even if it's not managed automatically,
will help users.
* I see ~/.mason used as a common area for mirroring remote packages
>> locally. That seems like a good default location, however it may not be
>> ideal for all use cases especially if the home directory is small and the
>> size and/or number of packages is large. What about supporting an
>> environment variable that allows the user to change the location, like
>> MASON_LOCAL_ROOT or MASON_LOCAL_REPO or similar?
>>
>
> This is not compatible with the XDG specification, and so becomes a
> huge irritation. Gradle, Cargo, and Dub are really irritating for doing
> this as well.
>
It is common on HPC systems for home directories *not* to be mounted on the
compute nodes, so the ability to bundle Mason packages in a user-specified
location (e.g., on a Lustre partition) is helpful, if not essential.
Support for something like Python's virtual environments could also be
helpful. Since Chapel itself has a number of configuration options, users
may want (or need) to keep separate and distinct instances of Chapel
configurations and Mason package installations.
Thanks,
Nick
------------------------------------------------------------------------------
_______________________________________________
Chapel-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/chapel-developers
