Re: [elm-discuss] Installing packages direct from github

[Oliver Searle-Barnes]

Ah, good to know. A note in the readme would be good.

On Friday, 19 August 2016 14:56:19 UTC+2, Janis Voigtländer wrote:
>
> Aside: For the specific case of 
> https://github.com/circuithub/elm-maybe-extra, you might more easily have 
> switched to https://github.com/elm-community/maybe-extra, which is 
> maintained, is being kept up to date with Elm compiler releases, and is the 
> “official successor” of circuithub/elm-maybe-extra (with circuithub‘s 
> blessing, as you can see here 
> 
> ).
> ​
>
> 2016-08-19 14:37 GMT+02:00 Oliver Searle-Barnes  >:
>
>> I've recently started using 
>> https://github.com/gdotdesign/elm-github-install in place of the usual 
>> package manager. It allows you to install dependencies direct from github 
>> whilst still handling the semantic versioning resolution.
>>
>> Here are some scenarios where this is really helpful
>>
>> 1) Fixing bugs - if I use someone else's library and find a bug in it 
>> then most likely it's far more important to me that it's fixed than it is 
>> for them. If I can install the dependency from github then I can simply 
>> fork it and use my fork until the PR has been merged in. If I have an app 
>> in production this is absolutely essential, the only alternative is to 
>> copy/paste the code into my project and apply a fix there which seems a 
>> poorer solution in every way.
>>
>> 2) Applying updates - similar to (1) if I use someone else's library and 
>> I need to update it for elm 0.17 for instance then I can just fork it and 
>> apply the changes. 
>>
>> 3) Using dependencies that rely on native code - I'm aware of the 
>> argument that native code should be discouraged as far as possible and that 
>> this would make it too easy to reach for native code where an Elm solution 
>> would be better. My counter argument would be that the community is 
>> currently small but full of people who are trying to encourage adoption of 
>> Elm at their workplace. Elm becomes a much harder sell if you can't rely on 
>> existing javascript solutions when necessary. I think it's right that 
>> packages with native code are kept out of http://package.elm-lang.org/, 
>> this sends a strong signal that pure Elm solutions are very much preferred. 
>> The community already has the notion that javascript code should be 
>> considered "unsafe" so I feel confident that there would be a trend towards 
>> pure Elm solutions over time.
>>
>> To give you two concrete examples where I've already found this really 
>> useful:
>>
>> https://github.com/zapnito/local-storage - a fork of 
>> https://github.com/elm-lang/local-storage, while this is a draft it's a 
>> practical implementation written by the author of Elm (thanks Evan!) and 
>> it's highly unlikely that I'm going to improve on it. By using it I'm 
>> accepting a degree of risk, changing signatures, unexpected behaviour etc. 
>> but it still seems far more preferable to the other options.
>>
>> https://github.com/zapnito/elm-maybe-extra - a fork of 
>> https://github.com/circuithub/elm-maybe-extra, it has seem really handy 
>> functions that I wanted to use but it hadn't been updated for Elm 0.17, it 
>> took a couple of minutes to fork it, update the dependencies, change a 
>> `package` statement and have it installed in my project ready to go.
>>
>> It would be great to see official support for these workflows. I think it 
>> would help adoption (as a developer intending to put an Elm in production 
>> it gives me a lot more confidence that I can solve any issues I come across 
>> without depending on 3rd parties) without harming the "gold standard" of 
>> the packages at package.elm-lang.org.
>>
>> -- 
>> 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.
>>
>
>

-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [elm-discuss] Installing packages direct from github

[Janis Voigtländer]

Aside: For the specific case of
https://github.com/circuithub/elm-maybe-extra, you might more easily have
switched to https://github.com/elm-community/maybe-extra, which is
maintained, is being kept up to date with Elm compiler releases, and is the
“official successor” of circuithub/elm-maybe-extra (with circuithub‘s
blessing, as you can see here

).
​

2016-08-19 14:37 GMT+02:00 Oliver Searle-Barnes :

> I've recently started using https://github.com/
> gdotdesign/elm-github-install in place of the usual package manager. It
> allows you to install dependencies direct from github whilst still handling
> the semantic versioning resolution.
>
> Here are some scenarios where this is really helpful
>
> 1) Fixing bugs - if I use someone else's library and find a bug in it then
> most likely it's far more important to me that it's fixed than it is for
> them. If I can install the dependency from github then I can simply fork it
> and use my fork until the PR has been merged in. If I have an app in
> production this is absolutely essential, the only alternative is to
> copy/paste the code into my project and apply a fix there which seems a
> poorer solution in every way.
>
> 2) Applying updates - similar to (1) if I use someone else's library and I
> need to update it for elm 0.17 for instance then I can just fork it and
> apply the changes.
>
> 3) Using dependencies that rely on native code - I'm aware of the argument
> that native code should be discouraged as far as possible and that this
> would make it too easy to reach for native code where an Elm solution would
> be better. My counter argument would be that the community is currently
> small but full of people who are trying to encourage adoption of Elm at
> their workplace. Elm becomes a much harder sell if you can't rely on
> existing javascript solutions when necessary. I think it's right that
> packages with native code are kept out of http://package.elm-lang.org/,
> this sends a strong signal that pure Elm solutions are very much preferred.
> The community already has the notion that javascript code should be
> considered "unsafe" so I feel confident that there would be a trend towards
> pure Elm solutions over time.
>
> To give you two concrete examples where I've already found this really
> useful:
>
> https://github.com/zapnito/local-storage - a fork of
> https://github.com/elm-lang/local-storage, while this is a draft it's a
> practical implementation written by the author of Elm (thanks Evan!) and
> it's highly unlikely that I'm going to improve on it. By using it I'm
> accepting a degree of risk, changing signatures, unexpected behaviour etc.
> but it still seems far more preferable to the other options.
>
> https://github.com/zapnito/elm-maybe-extra - a fork of https://github.com/
> circuithub/elm-maybe-extra, it has seem really handy functions that I
> wanted to use but it hadn't been updated for Elm 0.17, it took a couple of
> minutes to fork it, update the dependencies, change a `package` statement
> and have it installed in my project ready to go.
>
> It would be great to see official support for these workflows. I think it
> would help adoption (as a developer intending to put an Elm in production
> it gives me a lot more confidence that I can solve any issues I come across
> without depending on 3rd parties) without harming the "gold standard" of
> the packages at package.elm-lang.org.
>
> --
> 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+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[elm-discuss] Installing packages direct from github

[Oliver Searle-Barnes]

I've recently started 
using https://github.com/gdotdesign/elm-github-install in place of the 
usual package manager. It allows you to install dependencies direct from 
github whilst still handling the semantic versioning resolution.

Here are some scenarios where this is really helpful

1) Fixing bugs - if I use someone else's library and find a bug in it then 
most likely it's far more important to me that it's fixed than it is for 
them. If I can install the dependency from github then I can simply fork it 
and use my fork until the PR has been merged in. If I have an app in 
production this is absolutely essential, the only alternative is to 
copy/paste the code into my project and apply a fix there which seems a 
poorer solution in every way.

2) Applying updates - similar to (1) if I use someone else's library and I 
need to update it for elm 0.17 for instance then I can just fork it and 
apply the changes. 

3) Using dependencies that rely on native code - I'm aware of the argument 
that native code should be discouraged as far as possible and that this 
would make it too easy to reach for native code where an Elm solution would 
be better. My counter argument would be that the community is currently 
small but full of people who are trying to encourage adoption of Elm at 
their workplace. Elm becomes a much harder sell if you can't rely on 
existing javascript solutions when necessary. I think it's right that 
packages with native code are kept out of http://package.elm-lang.org/, 
this sends a strong signal that pure Elm solutions are very much preferred. 
The community already has the notion that javascript code should be 
considered "unsafe" so I feel confident that there would be a trend towards 
pure Elm solutions over time.

To give you two concrete examples where I've already found this really 
useful:

https://github.com/zapnito/local-storage - a fork of 
https://github.com/elm-lang/local-storage, while this is a draft it's a 
practical implementation written by the author of Elm (thanks Evan!) and 
it's highly unlikely that I'm going to improve on it. By using it I'm 
accepting a degree of risk, changing signatures, unexpected behaviour etc. 
but it still seems far more preferable to the other options.

https://github.com/zapnito/elm-maybe-extra - a fork 
of https://github.com/circuithub/elm-maybe-extra, it has seem really handy 
functions that I wanted to use but it hadn't been updated for Elm 0.17, it 
took a couple of minutes to fork it, update the dependencies, change a 
`package` statement and have it installed in my project ready to go.

It would be great to see official support for these workflows. I think it 
would help adoption (as a developer intending to put an Elm in production 
it gives me a lot more confidence that I can solve any issues I come across 
without depending on 3rd parties) without harming the "gold standard" of 
the packages at package.elm-lang.org.

-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.