Hi Thomas, Thanks for the feedback!
On 7/26/16, 12:05 AM, "Thomas Van Doren" <[email protected]> wrote: >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? As noted in CHIP 9, the package manager design presented is heavily based on Rust's Cargo. There are many features of Cargo that Mason will eventually support that were not explicitly stated in this CHIP. As of now, we fully intend to support a feature similar to Cargo's dev-dependencies [1] at some point. However, I imagine this is a feature that will come at later stages, when things like test runners and deployment packages become more relevant for Chapel. [1] http://doc.crates.io/specifying-dependencies.html#development-dependencies >* 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. Yes, we fully intend to adopt some flavor of dependency grammar. Continuing the variations on a theme of "let's not reinvent the wheel, especially for package management", our design will closely follow that of Cargo's grammar, which utilizes the semantic versioning as a default behavior [2]. [2] http://doc.crates.io/specifying-dependencies.html >* 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? First, to clarify: multiple scms will be eventually supported. We are starting with git support out of simplicity for the first pass of the package manager. Again, we followed Cargo's lead here by using the key name to identify the type of scm, rather than relying on parsing the URL or suffix. Similarly, we are using the key name to tell us what kind of revision the field contains, where "tag" would be specific to "git", but "rev" would be more general. We hadn't considered the alternative too strongly - do you think there are disadvantages to our approach? >* 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 ><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 <http://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 <http://github.com> source, even though the system doesn't have >access to >github.com <http://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! As the CHIP mentions, our long term goal is to eventually support a central repository that mirrors both the package manifest file and the package contents. When this feature is complete, I think support for user-hosted registries and local cached registries will be a natural step forward. From what I understand, the Cargo community has also realized the value in this use case, and made recent efforts in supporting this feature. We are very aware of the problems coupled with package authors controlling package accessibility via repository availability, etc., which is why we emphasize that this initial registry design is a stepping stone towards the long term goal of a registry with fully cached packages. While the use cases you mentioned are not included in the current design plan, I think they are useful to keep in mind when developing the first version, so that we don't prohibit their eventual development. >* 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? Yes - ~/.mason will only be a default location. Users can change this location with an environment variable, as you suggest. >* 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.) Yes - The goal of the first version is to get something useful to the users, with minimal bells and whistles. We fully intend on supporting other scms in future releases. >Overall I'm really excited for this work, and look forward to using mason. Thanks! We are too - and thanks again for the feedback. We will be sure to update the CHIP in order to clarify the ambiguities you've brought up here. Best, Ben On 7/26/16, 12:05 AM, "Thomas Van Doren" <[email protected]> wrote: >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 ><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 <http://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 <http://github.com> source, even though the system doesn't have >access to >github.com <http://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 > > > > > > > ------------------------------------------------------------------------------ _______________________________________________ Chapel-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/chapel-developers
