There is always this: https://github.com/gdotdesign/elm-github-install
Install via:
```sh
npm install -g elm-github-install
```
With this usage:
```json
# elm-package.json
{
...
"dependencies": {
...
"githubUser/repoName": "desiredVersion <= v < someLargerNumber",
"NoRedInk/nri-elm-css": "1.3.0 <= 1.3.0 < 2.0.0",
...
}
...
}
```
Then this to install them:
```sh
elm-github-install
```
On Monday, November 21, 2016 at 11:49:17 AM UTC-7, Michel Rijnders wrote:
>
> On Monday, November 21, 2016 at 3:40:02 PM UTC+1, Peter Damoc wrote:
>>
>> On Mon, Nov 21, 2016 at 1:42 PM, Michel Rijnders <[email protected]>
>> wrote:
>>
>>> The issue is that somebody forked our package (truqu/elm-base64) and
>>> published it, so now there's two (nearly) identical packages, potentially
>>> causing confusion.
>>>
>>
>> This is a more interesting issue to discuss.
>>
>> On one side, there should be freedom to fork and improved/change a
>> package (as long as your license allows it).
>> On the other side, I would not want nearly identical packages creating
>> noise in the package manager.
>>
>
> Totally agree, but in our case the fork was done solely because our
> package hadn't been upgraded to 0.18 yet. So once we upgraded our package
> there were two indentical packages. (Or nearly identical, because they
> forgot to upgrade the tests.)
>
> IMO having a way to install packages from other sources than
> package.elm-lang.org would solve this.
>
>
>>
>>
>>
>> --
>> There is NO FATE, we are the creators.
>> blog: http://damoc.ro/
>>
>
--
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.
