Hey, author of elm-github-install here.

it resolves the git ref then pulls the version number in from it's 
> elm-package.json

This is basically how it works and it adds the ref as the build number 
`1.0.0+master` , so this way it tracks what version to resolve and what 
code to use eventually.

As I read this thread this morning, I realized that I can make the local 
repositories work along with using different named repositories (forks) for 
a package. I threw together a prof of concept for it:
https://github.com/gdotdesign/elm-github-install/pull/14

The basic method works:
{
  "dependencies": {
    "elm-lang/svg": "2.0.0 <= v < 3.0.0",
    "elm-lang/dom": "1.1.1 <= v < 2.0.0",
    "elm-lang/core": "5.0.0 <= v < 6.0.0"
  },
  "dependency-sources": {
    "elm-lang/core": {
      "url": "file:///path-to/elm-lang/core",
      "ref": "master"
    }
  }
}

However I'm stuck a little and I would appreciate your thoughts on how to 
handle transitive versions: what are the priorities when dealing with 
different versions, this is what I am suggesting:

   - 2 - current packages dependency - if the current package (the one we 
   are installing dependencies for) sets a source it will be the one we use
   - 1 - packages dependency - if the current package doesn't have 
   dependency for a package but an other has we use that 
   - 0 - Github - if no package defines dependency for a package we fall 
   back to Github

Let me know if you are trying this branch out.

On Wednesday, February 1, 2017 at 10:57:43 PM UTC+1, Oliver Searle-Barnes 
wrote:
>
> elm-github-install has a separate dependency-sources section which you can 
> use to override the dependency versions. The readme has the following 
> example
>
>   "dependencies": {
>     "gdotdesign/elm-install-test": "1.0.0 <= v < 2.0.0",
>     "elm-lang/core": "5.0.0 <= v < 6.0.0",
>     "elm-lang/svg": "2.0.0 <= v < 3.0.0",
>     "elm-lang/dom": "1.1.1 <= v < 2.0.0"
>   },
>   "dependency-sources": {
>     "elm-lang/core": "[email protected]:elm-lang/core",
>     "gdotdesign/elm-install-test": {
>       "url": "[email protected]:gdotdesign/elm-install-test",
>       "ref": "master"
>     }
>   }
>
>
> So you would specify your file:///uri in the "url" property and whatever 
> git treeish value you want in "ref" (e.g. master). I'm not entirely sure 
> how it works in the case that you override a transitive dependency. It may 
> just ignore semantic versioning completely and use the version you've 
> specified in the git reference or perhaps it resolves the git ref then 
> pulls the version number in from it's elm-package.json. Because Elm uses a 
> flat dependency structure specifying the dependency explicitly will be 
> enough to constrain the transitive version as well.
>
>
> On Wednesday, 1 February 2017 17:58:34 UTC+1, Rupert Smith wrote:
>>
>> On Wednesday, February 1, 2017 at 4:57:22 PM UTC, Rupert Smith wrote:
>>>
>>> This is actually something I have been wondering how to do because I 
>>> wanted to do some hacking on elm-lang/virtual-dom, but I have no idea how 
>>> to import the hacked version into another project in order to try it out.
>>>
>>
>> Also, one does not normally include elm-lang/virtual-dom explicitly, it 
>> gets sucked in as a transitive dependency of elm-lang/html or elm-lang/svg. 
>> Is it possible to override transitive dependencies? 
>>
>

-- 
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 [email protected].
For more options, visit https://groups.google.com/d/optout.

Reply via email to