Feature Tracker: Local Dependencies and/or Arbitrary git:// Dependencies about elm-package

[evancz]

I know people want this, so I'd rather trick in my personal todo list rather than here.

[MatthiasWinkelmann]

I would really prefer if issues that people obviously want just remain open so that I can follow along, instead of the constant closing, moving, aggregating, to-do-listing and just-disappearing.

I know open issues can feel like, well, "issues". But people understand that these things take time, and I know many projects with 1000+ open tickets where I would never take that as a sign of low quality or any other problems (c.f. Tensorflow, VSCode, Ansible)

As it is currently done, I keep chasing issues from one ticket to another to find the one that's actually relevant. Only to often arrive at a dead end such as this.

Edit: This issue seems to be tracked at elm-lang/elm-make#59 currently.

[okkero]

Any news on this? I love Elm as a programming language, but I think having private dependencies is a huge deal. I really hope this gets fixed soon. It's been two years now and some really great solution proposals. What gives?

[Pilatch]

Try this out and see if it helps - https://www.npmjs.com/package/elm-github-install

[evancz]

I am having the same difficulty with elm-lang/core, but I do not want to do something drastic to resolve this. My main worry is that we do something that decreases reproducibility.

Am I correct that the local-dependencies.json idea is primarily for people who want to test packages or code with unreleased versions? It's just a way to say, "actually, look at the code here"?

I think depending on arbitrary git repos is problematic for a couple reasons.

1. Tags can be moved and deleted.
2. Repos can be deleted.

When reproducibility is a goal, I think these are a big deal.

What I had in mind that may resolve the root issues behind your two suggestions. I'd like to make it possible to list multiple package repositories. At the moment, there is only the central public one at package.elm-lang.org, but for industrial users who don't want everything open source, the ideal thing is to run the same service internally. That way you can publish and get all the same benefits without releasing the code publicly. You'd have a config file somewhere that lists package repos you care about: [ "http://package.elm-lang.org", "https://intranet.mycompany.com", "http://localhost:8000" ]

Does this idea address the root concerns you have?

As I'm writing this, I see that I don't fully understand the goals of the git repo thing. Can you say exactly what you want to do that your suggestion is solving?

[dackerman]

As a developer, when I push up packages to an official repo, I feel a responsibility to maintain that code for others. Here's two examples I can think of:

I depend on a library from elm-lang, but find a bug. I send a pull request to fix it, but want to depend on the fixed version now. I suppose a local server would work here, but it's a little annoying to need a server running to build my dependency. What if I want to share my code with a friend? Am I right to think they'd also have to check out the fixed version of my dependency manually, build it, and then serve it in their own local repository? (Assume we're not at a company where we might have a central private repository).

What if a package maintainer abandons their release on elm-lang.org, but I want to make fixes and continue working on it for my own project? Once again, I could maintain my own repo server, but that imposes extra work on everyone that might want to use my code. However, I don't really want to push my "fork" up to elm-lang.org because not only might it confuse people, but I don't want to be on the hook for maintaining that project for years to come when I wasn't the original developer.

However, I can see the consequences of allowing another developer to pull from a git repository means it may not conform to the appropriate versioning semantics or even exist. I guess that would be a decision any developer wanting to use my code would have to make - is it worth the potential instability?

Anyway, these feelings may be irrational or have other simpler solutions - so what would you do in these cases Evan?

[Raynos]

@evancz

I think depending on arbitrary git repos is problematic for a couple reasons.
Tags can be moved and deleted.
Repos can be deleted.
When reproducibility is a goal, I think these are a big deal.

Suggestion:

• Mark application as "application" and make them unpublishable
• Enforce that NO module in the official registry has a git dependency
• Allow git dependencies for applications only and for nested git modules

This means the following holds. All modules are on the registry and if you install any module of the registry which has dependencies it will only pull dependencies of the registry.

Application developers can depend on private modules through git links.

Application developers can fork a dependency on git and change a nested dependency with a git link. This allows them to change any dependency as long as they convert all parents to git dependencies.

Assumption: We assume application developers are smart and use their own cached git servers with immutable tags. Application developers can shoot themself in the foot, library developers cannot shoot themself in the foot

[TheunisKotze]

I like Raynos' idea, only allow published dependencies in published packages. Arbitrary git dependency would be really helpful, I'm currently working off an unmerged core branch, and though its api might change slightly before being merged, it's really useful to move forward using it

[evancz]

Please share your opinions on this draft of this idea!

[johnpmayer]

Oh thanks I should read through this thread
On Feb 9, 2015 6:21 PM, "Evan Czaplicki" [email protected] wrote:

Please share your opinions on this draft of this idea
https://groups.google.com/forum/#!topic/elm-discuss/6QYqpBaGW1c!

—
Reply to this email directly or view it on GitHub
#87 (comment).

[thSoft]

I really like John's proposal. Is there any workaround until this issue is resolved other than copying the clone of the dependency to be used?

[jconti]

A smooth solution to this may encourage folks to send pull requests and fixes instead of just logging complaints. A smooth workflow for forking and running libraries could fracture the community if done incorrectly (as evancz points out), but done well this could really boost library maintenance productivity IMO.

[wmakley]

Has anything changed on this front recently? I just finished a pretty big project with several useful libraries that really that should be published packages, but I as I can't include the WIP packages in my project, I'm not sure how to refactor them. I also want to fork and improve some libraries I ended up using, but same problem. I really love this language, and want to give back!

[evancz]

elm/package.elm-lang.org#105 is asking about some of the same stuff and I'm trying to guide it towards getting some concrete proposals out there so we know all the details that'd change and their implications. I think this is increasingly important so I expect it to get attention relatively soon.

[justgage]

For what it's worth I think having private packages on package.elm-lang.org would fit my needs.