I'm excited to see this proposal! This will make it easier for developers
to build and share Chapel code with the community.
A few pieces of feedback:
* In other package managers, for example npm and maven, there is a
distinction between types of dependencies. With npm there are both regular
dependencies <https://docs.npmjs.com/files/package.json#dependencies> that
are strictly required for using a package, devDependencies
<https://docs.npmjs.com/files/package.json#devdependencies> which are only
available when npm is actually running (e.g. things like test runners and
deployment packages), and a few others. Maven also supports several scopes (
docs
<https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#Dependency_Scope>).
What do you think about supporting different types of dependencies in mason?
* Will there be support for a simple grammar for dependency version ranges?
One of the benefits of using semver is a package can safely depend on a
major version of another package without specifying minor or bugfix
version, i.e. package A version 1.2.3 can depend on package B version 2.X.Y
where X and Y are any values (resolved on a sync command). NPM
<https://docs.npmjs.com/files/package.json#version>, rubygems
<http://guides.rubygems.org/patterns/#pessimistic-version-constraint>, maven
<https://docs.oracle.com/middleware/1212/core/MAVEN/maven_version.htm#MAVEN402>,
and python setuptools
<http://peak.telecommunity.com/DevCenter/setuptools#declaring-dependencies>
each have simple grammars that enable dependencies to be specified across a
range of versions.
* The source map in the package configuration stanza has keys "git" and
"tag" in the example Mason.toml file. This makes me think I could also add
keys for svn and hg, but then I'm not sure how to specify different
tags/commits for each scm. How about renaming the git key something like
scmUrl or url (and requiring a suffix to determine the protocol)? Or is it
the case that multiple scms are not supported?
* I am wary of having the source location tightly coupled with the package
information. The leftpad fiasco with NPM
<http://blog.npmjs.org/post/141577284765/kik-left-pad-and-npm> is a great
example of the kind of issues that can happen when a single source location
is tied to a package. Maven, for example, decouples the remote location
from the package--where maven looks for packages is configured separately
from the actual packages.
Two use cases that may be interesting to think about supporting with Mason
(in lieu of suggesting a way to support them, since I'm not entirely sure):
1. Support having mason registries that are not located at
https://github.com/chapel-lang/mason-registry. If I am working on
proprietary libraries, it would be great if I could use
https://github.com/chapel-lang/mason-registry and
https://my-internal-git-server/proprietary-chpl-registry.git as the mason
registries. The former is the public registry and the latter is a private
registry that has chapel packages I developed. The packages in the private
registry are proprietary and should not be shared outside my internal
network.
2. Support having internal mirrors of specific packages. For example, if I
have a package with a Mason.lock file that has a dependency that is locked
to git+
https://github.com/tzakian/curl.git#9f35b8e439eeedd60b9414c58f389bdc6a3284f9
and I am on a system that does not have access to github.com , I want a way
to tell Mason how to find the curl package with commit 9f35b... somewhere
else in my internal network. (I download the package with Mason.lock file
from https://my-internal-git-server/chapel-mason-registry-mirror.git, an
internal copy of the public registry updated daily. That's why it has a
github.com source, even though the system doesn't have access to github.com
.)
It may not be necessary (or even reasonable) to support these use cases in
the first version of mason. It would be great if the first version did not
prohibit them from being supported in the future, though!
* 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?
* All of the examples use git repositories for the central storage for
remote packages. Will that be the only supported way to distribute packages
in the first release? (That sounds good to me; this is just curiosity.)
Overall I'm really excited for this work, and look forward to using mason.
Thanks!
Thomas
Thomas Van Doren
[email protected]
On Tue, Jul 19, 2016 at 5:02 PM, Preston Sahabu <[email protected]> wrote:
> Hello Chapel Users and Developers,
>
> We are pleased to announce our plans for Mason, a dependency manager and
> build tool for Chapel programs and libraries. The full proposal can be
> found here:
>
> https://github.com/chapel-lang/chapel/blob/master/doc/chips/9.rst
>
> Today we bundle external modules in the standard library, but this is not
> conducive to a healthy Chapel ecosystem. With that goal in mind, we aim to
> make creating, publishing, and incorporating community packages as
> seamless as possible.
>
> Though we do not plan to include Mason with the 1.14 release, your
> feedback will help refine our proposal and set its priority for 1.15. We
> look forward to hearing from all of you!
>
> Thank you,
>
> Preston Sahabu and Ben Albrecht
> Chapel Team
>
>
> ------------------------------------------------------------------------------
> What NetFlow Analyzer can do for you? Monitors network bandwidth and
> traffic
> patterns at an interface-level. Reveals which users, apps, and protocols
> are
> consuming the most bandwidth. Provides multi-vendor support for NetFlow,
> J-Flow, sFlow and other flows. Make informed decisions using capacity
> planning
> reports.http://sdm.link/zohodev2dev
> _______________________________________________
> Chapel-developers mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/chapel-developers
>
>
------------------------------------------------------------------------------
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are
consuming the most bandwidth. Provides multi-vendor support for NetFlow,
J-Flow, sFlow and other flows. Make informed decisions using capacity planning
reports.http://sdm.link/zohodev2dev
_______________________________________________
Chapel-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/chapel-developers
