Hello Russel, Thanks for your insight on what the rest of the package management community is doing!
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. Thanks, Preston On 7/26/16, 9:02 AM, "Russel Winder" <rus...@winder.org.uk> wrote: >On Tue, 2016-07-26 at 00:05 -0700, Thomas Van Doren wrote: >> >> [Š] >> * 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-depende >> ncy-mechanism.html#Dependency_Scope>). >> What do you think about supporting different types of dependencies in >> mason? > >I have not used NPM much but am a regular user of Gradle (rather than >Maven), Cargo, and Dub. I am just getting into Glide. > >There are two things going on here: dependency management; and build. >Are all dependencies to be managed as source code (which is what >effectively happens with Go, Dub, and Cargo, or are precompiled >dependencies allowed as in Gradle (and Maven). Is multi-language build >allowed? Build systems such as SCons, CMake, etc. are generally very >good at multi-language builds. Gradle is. Cargo, Go and Dub are not. > >Cargo gets the build of downloaded source more or less correct, Dub >fails the issue here is location of compilation products and >libraries. Cargo is per project, which means compiling dependencies >many times but allows for platform separation on shared filestores. Dub >keeps the compilation products per user or global which is great for >sharing except on share filestores with almost but not quite compatible >operating systems and tool chains. > >> * 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-depende >> ncies> >> each have simple grammars that enable dependencies to be specified >> across a >> range of versions. > >Gradle uses + for the biggest value you can find in the repository and >works very well. > >Go allows for getting dependencies from arbitrary Git, Bazaar, or >Mercurial repositories. This is great for a liberal approach to >development of software, but terrible for quality control and building >a shared quality milieu. Also Go has serious problems with vendoring, >well they are being sorted now and Glide is the latest tool in that >arena. > >D's dub and repository, Ceylon's Herd, and Rust's Cargo repositories >show a balance between freedom and centralized quality. I am not sure >the Go/Glide solution has caught up as yet. > >> * 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? > >There are a million and one specification formats for this Rust uses >TOML, Dub uses SDL (or JSON), that is fine for dependencies per se but >misses how to control non-convention compliant builds. Maven requires >new plugins, but Gradle allows for Kotlin or Groovy encoded build >logic. This makes the general build problem so much easier. I know >Maven is dominant in the JDK world currently, but that will not last >much longer, Gradle is going to sweep away the Maven base as new >projects happen. > >Git is seriously dominant but Bazaar and Mercurial are still there, >worth keeping them in the mix. > >> * 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. > >Maven solves a different problem to the one Cargo, Dub, and Gradle >solve when it comes to configuration. The Java mechanisms are different >to native code ones, Gradle supports C++ builds as well >Java/Kotlin/Ceylon/Scala/Groovy/Frege ones. This has caused a total >revolution in the way Gradle supports the JDK languages, for the >better. Maven is stuck in it's ways. Is the decoupling that Bintray and >Maven Central effect actually any better than the direct dependencies >as per Cargo or Dub. I am not convinced. Having the semi-indirection of >Dub and Cargo is though vastly superior to the direct statement of >repository in Go imports. > >> 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. > >I would suggest this is a must. Cargo and Dub allow this, and it is >essential. Go always has this, it has no central system other than the >actual distribution. > >> 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#9f35b8e439eeedd60b9414c58f389bdc6 >> a3284f9 >> 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 >> .) > >Shouldn't this be covered by local caching of the dependencies. There >just has to be an offline mode. Gradle got this and it (mostly) works. >Dependency/Build systems that require online access even after the >dependencies have been got lead to bad language and a change of >programming language. > >> 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? > >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. > >> * 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 > >Rust and Cargo are doing a fairly good job so they are worth following. >Go has some issues that really do not apply in Chapel. Dub is doing >some good stuff, most is covered by Cargo but there are a few >interesting things in D that are not in Rust. For example D has very >simple ways of dealing with C linkage dependency hooks. Rust still >isn't that great, at least not with the C libraries I play with. > >Chapel needs to be able to deal with C and C++ libraries very easily, >as D can but Rust and Go have problems with. > >If I can use GStreamer and Gtk directly from Chapel for example, then >there is the possibility of making inroads on Python/Julia/R in the >data science milieus. ------------------------------------------------------------------------------ _______________________________________________ Chapel-developers mailing list Chapel-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/chapel-developers
