Revising elm-package.json for more scenarios

[evancz]

This is based on @laszlopandy's issue #49 where he proposed adding two fields: "main-modules": [ "Main" ] and "build-output": "build/my-elm.js". After the discussion there, here is the revised version.

The elm-package.json file would be renamed to elm-project.json with the goal of covering the two major kinds of projects: packages that want broad dependencies and products that want exact dependencies.

If elm-project.json has a exposed-modules field, it must be a package. If it has a main-modules field, it must be a product. These would be mutually exclusive and the product version would be the default.

For Products

For products, the elm-project.json file would be something like this:

{
    "source-directories": [
        "src"
    ],
    "main-modules": [
        "Main"
    ],
    "output": "build/my-elm.js",
    "dependencies": {
        "elm-lang/core": "2.1.0"
    },
    "elm-version": "0.15.1"
}

Notice that the dependencies are all exact versions here. This means you can never have anything freaky happen due to some weird change in a dependency. (Oh, unless there is some weird change in a transitive dependency and the solving algorithm is nondeterministic or changes for some reason.)

My main questions questions are:

1. Should the elm-version field be exact too? What if someone tries to use 0.15.2? Should it fail? This whole flow seems weird.
2. What is the experience do people have when installing a new package? Maybe you can add the package, but the precise versions listed need to be slightly updated. The dependency solving algorithm would need to map 2.4.2 to 2.0.0 <= v < 3.0.0 or something like or it will miss a lot of solutions and the user will have to work all this out in their head.

I don't want to discuss question 2 here. This points at having a more flexible solver and that's a discussion of its own.

For Packages

The elm-project.json file would look something like this:

{
    "version": "1.0.0",
    "summary": "helpful summary of your package, less than 80 characters",
    "repository": "https://github.com/USER/PROJECT.git",
    "license": "BSD3",
    "source-directories": [
        "src"
    ],
    "exposed-modules": [
    ],
    "dependencies": {
        "elm-lang/core": "2.0.0 <= v < 3.0.0"
    },
    "elm-version": "0.15.0 <= v < 0.16.0"
}

This would work just like the current elm-package.json so I don't have any big concerns here.

---

Issue Updates

• Guess github user name? Infer intial repository from .git/config elm-package#131

[laszlopandy]

👍

[rtfeldman]

This seems awesome!

As for Question 1, I think it makes sense to fix elm-version. Otherwise, suppose someone has elm-version set to 0.15.0 <= v < 0.16.0, then they install a package that works for them (on, say, 0.15.2) but which doesn't work on 0.15.1, and now their coworker is confused as to why it broke.

Also, I've experienced the pain of working on a product team where the troubleshooting question gets asked "wait, what version of Ruby are you running?" Would be nice to just rule that out.

The only drawback that comes to mind is that if you have multiple projects that you want to work on (say, bleeding edge side projects versus your work project that's slower to upgrade) switching elm-make versions back and forth could be annoying. That said, lots of languages run into this, and people have made community tools like rvm and nvm to make switching quick.

[avh4]

For supporting multiple versions on the same machine, I like the way python does it: the actual binary would be elm-0.15.1, elm-0.16.0, elm-make-0.15.1, etc; and elm, elm-make, etc would be links to (or copies of) the most-recently installed version.

[clembu]

Why force a repo field?

[rtfeldman]

@FacelessPanda I toned down your comment. If you'd like the original back, let me know and I'll send it to you.

[MrRacoon]

I'm also curious why the repo field requires a github address.

I'm working on an internal POC, that should definitely not go into github, and it's freaking some people out when they see this.

[MicahZoltu]

What is the status of this? It looks like it was opened a couple years ago but no progress on it. I'm trying to develop an app (not a library) and the current workflow is pretty uncomfortable. Not only can I not just tell my editor "elm-make" because I have to provide a bunch of CLI parameters, but I have to have a bunch of fields in elm-package.json that aren't relevant to my project because it thinks I am building a library.

I would really like to see some progress on the elm-project.json idea, it seems like all of the other stuff like version matching could be put in a separate issue rather than holding this issue back.

I want to be able to clone the repo and then run elm-make, not have to go and remember the obscure invocation necessary to build this particular app (elm-make app/client/App.elm --output app/client/app.js).

[lydell]

@MicahZoltu As far as I understand, there will be changes to elm-package.json in 0.19: https://groups.google.com/forum/#!topic/elm-dev/qdu3NqOqGrY

[sepbot]

Several closed issues regarding the mandatory repository field point to this one, but this one doesn't actually discuss the plans for the field. So if there is a different forum for discussing this matter please let me know.

The imposition of a particular company's offering of a specific version control system is a huge turn off for beginners. I think the matter should be given more priority as there is nothing worse than a beginner going to run elm-make and finding out that the language is not flexible enough for them to use anything besides Github. Especially considering this is likely to happen prior to them actually doing any actual coding, and while they're trying to do a simple hello world.

[rtfeldman]

The imposition of a particular company's offering of a specific version control system is a huge turn off for beginners.

It's really not. I talk to a ton of beginners and I'd estimate that maybe one in 200 even mention it after they find out about it. 🙂

I understand that this matters more or less to different people, and that's a totally fine preference to have, but it's tough to justify prioritizing something that only matters at all to a very small minority of people who come to Elm.

[yowzadave]

It's really not. I talk to a ton of beginners and I'd estimate that maybe one in 200 even mention it after they find out about it. 🙂

Put me down as a new user who was confused by this issue. Not a big deal, but it is something I spent a few minutes trying to figure out.

And there are a couple of other threads of users thinking this should be fixed in #188 and #71.

[EverybodyKurts]

I wasn't confused by the issue, but it seems like the repository field should allow more repos than just one for github. Like one of the previous posters mentioned, I'm working on internal pieces of code that isn't being hosted on github.

[zwilias]

@KurtRMueller The repository field is only relevant for libraries published through elm-package, not for applications. If I'm not mistaken, the repo field won't even be there for applications in 0.19 - I think this will make it much clearer that there is no point in changing it unless you're writing a package to publish, in which case it needs to be distributed through github, for now.

[evancz]

Something like this is slated for 0.19, so I do not think it makes sense to keep this open. It works like if I thought the original question through for a lot longer! 😃

I need to write upgrade docs which will explain the particular choices, so I will focus on doing that in a generic way rather than doing it in a one-off way here.