Non-published Dependencies

[John Mayer]

Currently elm projects can only depend on other Elm code from the official package repository. The official repository has nice guarantees (semver) but at some point it can't serve everybody's needs (experimental projects, behind-the-firewall, etc). Here's a brainstorm (at the interface level) to add this flexibility, followed by my thoughts.

{

    "version": "1.0.0",

    "summary": "helpful summary of your project, less than 80 characters",

    "repository": "https://github.com/USER/PROJECT.git",

    "license": "BSD3",

    "source-directories": [

        "."

    ],

    "exposed-modules": [],

    "dependencies": {

        "elm-lang/core": "1.1.0 <= v < 2.0.0"

    },

    "extra-dependencies": {

        "projectName1" : {

            "type" : "github",

            "id" : "johnpmayer/experimental",

            "tag" : "1.2.3"

        },

        "projectName2" : {  

            "type" : "git",

            "repo" : "https://myserver.org/myproject.git <or> m...@myhost.org:mydir/myrepo <or> file:////mywindowsmachine/myshare/mycode"

            "tag" : "1.2.3"

        },

        "projectName3" : {

            "type" : "zip",

            "url" : "https://myserver.org/mycode.zip <or> file:///mypath/mycode.zip"

        },

        "projectName4" : {

            "type" : "custom",

            "command" : "my_executable",

            "arguments" : [ "project", "1.2.3", "--flag" ]

        }

    }

}

• Extra dependencies are explicitly separate 
• Easy-ish backwards compatibility
• Encodes a culture of preferring the official package
• Trivial to reject publication of packages with extra dependencies
  
• (I'm not married to this - we could group with the other dependencies - but I find this is a bit cleaner)
  
• Extra dependencies must describe how to fetch
• Tagged by a type and whatever extra metadata is required by that specific type
• Some implementations built into elm-package
• Makes sense to have GitHub, regular git, zip file
• Built in implementations are expanded through Pull Requests (svn, mercurial)
• High standards for inclusion
• Also allow a custom type
• Basically an executable assumed to be on the user's path
• Maximum flexibility (and technically this is just another builtin)
• The actual contents of extra dependencies must still adhere to the regular package format

[Jeff Smits]

First off: This looks great :) I have some comments:

• I don't mind the explicit extra-dependencies. Let's not overthink and just do it like that, I don't think it's a big deal and it can always be changed in a later release. 
  
• Regular git is good enough, please don't support GitHub explicitly. We already favour GitHub by using it for the repos on the official repository. There is really no need when you can just plug in a link from GitHub like you normally do with git clone. 
• Perhaps allow branches as well as tags?
• Arbitrary executable is great of extensibility, but OTOH I dislike how open it is (consider the example below). I think I prefer explicit support on a per tool basis, by having someone who needs some tool make a pull request with the addition of a type. With the right code architecture that should be simple enough. 

    "Surprise!" : {

        "type" : "custom",

        "command" : "rm",

        "arguments" : [ "-rf", "~" ]

    }

--
You received this message because you are subscribed to the Google Groups "Elm Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elm-discuss...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[John Mayer]

Agree with all of your points, Jeff.

Any other thoughts? Else I'm going to go ahead and get started on this.

[Evan Czaplicki]

I'm curious to hear from all the people asking for this. I bcc'd some folks who I recall asking for this specifically.

I think the case I have in particular is testing elm-lang/core. The trick there is that the testing packages depend on old core. It's unclear to me how to resolve that nicely, or if that should even be a goal. Perhaps that's really the only time that kind of thing comes up, and we shouldn't be bending over backwards for a special case.

Otherwise, it looks good to me! I think it'd be good to work on a branch until we have a prototype.

[Max New]

This proposal seems fine to me.

On Monday, February 9, 2015 at 6:28:29 PM UTC-5, Evan wrote:

I'm curious to hear from all the people asking for this. I bcc'd some folks who I recall asking for this specifically.

I think the case I have in particular is testing elm-lang/core. The trick there is that the testing packages depend on old core. It's unclear to me how to resolve that nicely, or if that should even be a goal. Perhaps that's really the only time that kind of thing comes up, and we shouldn't be bending over backwards for a special case.

This could be solved by allowing multiple versions of the same package, right? I think that should be supported as well. I shouldn't have to use an old version of a package if some other library I'm using uses it internally. The problem with core is just an instance of a general problem.

[John Mayer]

Not sure what you mean by old core.

[Max Goldstein]

Presumably, if the new version of the core is untested, you want the tests to run using the old version of core.