What do you think to using the version from the elm-package.json in the 
cloned repo? That way it's as though you'd specified a hard constraint in 
elm-package.json (e.g. 1.2 <= v <= 1.2) and then you can follow the usual 
semantics.


On Thursday, 2 February 2017 07:48:48 UTC+1, Gusztáv Szikszai wrote:
>
> 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