Page MenuHomeSolus

Elm Platform (Elm programming language)
Closed, WontfixPublic

Description

Name: Elm Platform

Homepage: http://elm-lang.org/

Repository: https://github.com/elm-lang/elm-platform

Why should this be included in the repository?: To provide convenient access to an updated development environment for Elm programmers.

Is it open source?: Yes.

How many users do you anticipate will use this software?: Unknown. FWIW: It's a core language for a few companies such as Pivotal Tracker, CircuitHub and NoRedInk. There are a few conferences dedicated to it around the world. It's tracked by the TIOBE Index but it doesn't break top 50.

Tarballs composing the Elm platform:

Useful references:

Upstream Haskell script to build entire platform: https://github.com/elm-lang/elm-platform/blob/master/installers/BuildFromSource.hs
Bash adaptation of the Haskell script as used in Arch: https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=elm-platform

All dependencies are already packaged as far as I know.

asonix added a subscriber: asonix.Jul 10 2017, 2:14 AM
JoshStrobl triaged this task as Normal priority.Jul 30 2017, 2:28 PM
JoshStrobl moved this task from Backlog to Accepted For Inclusion on the Package Requests board.
Azphreal added a subscriber: Azphreal.

Is this possible to include as one package? Afaik the current package.yml spec doesn't allow for file renaming before the setup phase, so it tries to download all five as whatever the current version is, but it will only fetch the first because of naming conflicts.

@Azphreal these should be separate packages. The good news is that it looks like they are using Cabal, so you should be able to use the macros I added to ypkg.

Barksten added a subscriber: Barksten.EditedNov 28 2017, 11:39 AM

I would really love this since it's not (AFAIK) possible to install using npm (as recommended by https://guide.elm-lang.org/install.html, error: no access to /usr/lib64/node-modules/elm/Elm-Platform)):

I've found more time to work on this. Judging by other Haskell programs, we prefer to package libraries rather than use cabal to install them, correct?

I'm currently partway through the compiler package and about half of these libraries aren't packaged. Just confirming before I dive into dependency hell.

Dependency hell is a part of how we do Haskell. Sorry :/

Cabal isn't sensitive enough to how versions are handled to be trusted for reproducible builds. Plus, to my knowledge we are the only distro that ships haskell using dynamic libraries. On the plus side, I have created some pretty robust macros for building Cabal packages and got them put into ypkg. Do me a favor though and try and get them using Hackage source tarballs. Cuppa is designed to track upstream there so it'll save us trouble in the future. Hackage makes it slightly easier to track deps as well (though it will list deps of deps of deps...and so on as a single list for a given package). Rule of thumb: if Cabal doesn't ask for it, you don't need it.

Azphreal added a comment.EditedDec 7 2017, 4:18 AM

Nope, all good. I've been using Hackage to check dependencies for the most part, so that's fine.

Is there a way to install local packages to solbuild or have it resolve dependencies locally? Local repo or something? I can't see anything in the documentation.

EDIT: Pretty sure all extra packages are done, sans dependent building via solbuild. Issues are as follows:

  • elm-compiler depends on an old version of haskell-aeson
  • elm-compiler and elm-package depend on a non-latest release of haskell-binary (not yet packaged); may cause issues in future
  • elm-package depends on older versions of:
    • haskell-HTTP
    • haskell-http-client
    • haskell-http-client-tls
    • haskell-http-types
    • haskell-random, as a dependency for haskell-parallel-io (not yet packaged)
  • haskell-entropy (second-level dependency for elm-reactor; not yet packaged) has linking issues; the issues page on Github has a solution for Arch, as they have an alternate version of GHC for static linking

Looking for advice on how to proceed with older versions particularly. The linking issue seems to be solved by simply not compiling it dynamically (according to the issue), but I haven't experimented.

Is there a way to install local packages to solbuild or have it resolve dependencies locally? Local repo or something? I can't see anything in the documentation.

The local repo fairy https://solus-project.com/articles/packaging/local-repository/en/

I have most everything building properly. Just need to figure out what will happen with old versions listed above.

ianjvr added a subscriber: ianjvr.May 8 2018, 7:13 AM
This comment was removed by JoshStrobl.
JoshStrobl closed this task as Wontfix.Jun 25 2018, 7:58 PM
JoshStrobl added a project: Needs Maintainer.
JoshStrobl removed Azphreal as the assignee of this task.
JoshStrobl added a subscriber: JoshStrobl.

This has sat in accepted for inclusion for almost a year now. Clearly, there is a lack of demand for the inclusion of this software, nobody has stepped up to provide a patch, maintain it, and properly integrate it. Closing as a result. Feel free to reopen but only when someone offers a patch via our proper patch submission methods and volunteers to be maintainer.