-
-
Notifications
You must be signed in to change notification settings - Fork 254
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
stack setup #405
Comments
Thanks Tony. I've not really got my head around stack, do you have suggestions for how to make tidal more stack-friendly? |
Tidal is pretty friendly already - didn't take much to get it current. Just found the dependencies that weren't in stackage (hosc and microspec) and it all worked. I've thought about tidal and stack more generally and it's tricky to strongly recommend a stack install method. You could put it in stackage like Tidal used to be, but I'm not sure what that achieves. Usually, a package produces an executable or is a library primarily designed to be used by other libraries. I can't think of another haskell project where the main interface is, instead, via ghci. So A major design feature of stack is to isolate projects from global state. That's for people who have lots of haskell projects and a need to jump back and forth between ghc versions. Maybe that isn't the case for the majority of users. It kind of made sense to me to wrap Tidal in another package, but it also may be that an easier way is possible. The easiest is just to clone the Github repo, run My tentative conclusion is that it isn't suitable as the main install method, but is very useful for development, and the tidal-stack example I linked is then more a how-to. It was very easy to use stack in emacs - just needed to change tidal-interpreter etc. I haven't used atom but imagine it would be a similar story. |
Thanks @tonyday567, a really helpful summary. Maybe these are other reasons for using stack?
You imply tidal isn't in stackage any more - that's a shame! It'd be good to fix that if that's the case! Longer term I think tidal will be a binary that either mimics ghci or has a network interface e.g. a websocket api |
On hold in stackage: https://github.com/commercialhaskell/stackage/blob/master/build-constraints.yaml#L2689 hosc might be a current blockage. Latest tidal stackage: https://www.stackage.org/package/tidal Looks like tidal got bumped out on ghc-8.4. |
When I attempt to raise a PR to re-enable tidal I'm directed to check that this works first:
With tidal-0.9.10 replacing $package-$version, it ''doesn't'' work..
|
If I try the same in a checkout of master I get;
With --force applied I get the same error as above (Unable to parse cabal file for base-noprelude...) |
Try
I can build and test tidal-0.9.10 with the following stack.yaml:
|
Once tidal is back in stackage, I think the nix integration in stack is worth playing around with to aim for a one-click install. ref: https://chris-martin.org/2017/nix-for-stack-users |
Yes |
@tonyday567 I've got to nitpick re "stack is a wrapper around cabal, designed to help with dependencies, and to avoid global ghc an library installation." :-) -- you seem to refer to the legacy @yaxu regarding cabal compatibility: In my function as Hackage Trustee I've been busy fixing up a lot of Tidal's metadata on Hackage (see e.g. haskell-infra/hackage-trustees#172) ... it would be great for the user experience of Hackage/Cabal users (and also to reduce the workload for Hackage Trustees :) ) if Tidal would be a bit more proactive about cabal compatibility too! I'm happy to advise if you have any questions on how to do this. |
Hi @hvr, ah I had no idea that this work was needed and going on behind the scenes, thanks ! Very happy to be more pro-active, but I'm not clear on what this entails - what have we been doing wrong? By the way, currently tidal-midi is not compatible with the latest release of tidal, and there is not a plan to update it at the moment, so I think it is considered deprecated. This is because more advanced/stable midi support is available via the superdirt synth. |
@hvr Thanks for your engagement! It sounds like you still agree with my description of stack, and your point is that stack is unnecessary now that we have nix-style local builds in cabal? In other words, stack competes with Whatever the answer, tidal is a popular haskell project, with a growing user base of largely newcomers to haskell. Meanwhile, the main usage method is via running ghci (within Atom, emacs or command line) assuming that tidal (the library) is installed globally. Any thoughts or ideas on how to give users a smoother install and user experience would be awesome. |
Voting for Stack-specific instructions if nothing else. I'm a new user who has interest in Haskell independent of Tidal. I was advised by Haskellers to use Stack, but as a result the bootstrap script can't find ghci. |
Quoting myself from reddit where I'd strongly recommend newcomers to use Follow the simple instructions from https://github.com/haskell/ghcup to setup ghcup (i.e. download ghcup and set $PATH accordingly), and then as the initial setup do
then you can simply do
and Cabal will go ahead, figure out the build-plan and compile everything, and you'll be thrown into a GHCi repl with the tidal package in scope. It doesn't get easier than that! |
Now ghcup is suddenly the default way to install haskell for mac users, I'm finding it isn't very easy. In particular, adding to $PATH is difficult if you haven't never heard of that before.. |
@yaxu well,
and lateron in the installation, you get reminded multiple times (emphasized via terminal colors) about the PATH concern:
Do you have a suggestion on how to improve the wording above to make it easier to understand? |
Perhaps we just need a tidal install script that does the above, installs the tidal library too, and also installs and configures atom to call |
Just chipping in as I've just installed tidal on an ubuntu system (18LTS) and a Mojave install of OSX and things were moderately painful - stack was totally the way to go, so thanks for that pointer in the docs. Managed to get it working on both systems with atom and the plugin, but emacs requires a bit more gaffa tape I think... Wondering if it's worth updating the docs with a couple of lines on emacs/tidal/stack interplay? Will be investigating my emacs setup later based on @tonyday567's comment:
Happy to write a couple of lines of docs if/when I work out what's awry. Assume it's that emacs/tidal is using the wrong version of ghci, but hey. |
@the-frey It would be very helpful to know what you perceived as painful on Ubuntu and OSX in order to improve the situation with Haskell's standard tooling and avoid needing to resort to commercial 3rd party tooling. |
Possibly my unfamiliarity with stack but still not got my emacs settings worked out. Sorry, by 3rd party you mean -? AFAICT stack is MIT? |
Not sure how progress is going with this issue, but as a (setq tidal-interpreter "stack"
tidal-interpreter-arguments '("ghci" "--package" "tidal")
tidal-boot-script-path
(concat (substring
(shell-command-to-string "stack exec --package tidal -- bash -c \"ghc-pkg describe $(ghc-pkg latest tidal) | grep data-dir | cut -f2 -d' '\"")
0 -1)
"/BootTidal.hs")) This just sets the interpreter to |
Closing this for now, but please reopen if there's still an issue here. |
@bradrn As of the most recent Stackage LTS 15.11 (if not earlier), the format of the file containing the
|
I made a wrapper for tidal that uses stack to install tidal. It pins the tidal version to an exact commit (the stack convention) and is very useful for active development.
https://github.com/tonyday567/tidal-stack
I'm happy to document this if it's useful to others, but I wasn't sure exactly where to start (and if at all) with all the activity happening right now.
Tidal is very current and am pleased it works out of the box for ghc-8.6.2. Nice!
The text was updated successfully, but these errors were encountered: