I'm trying to write a small web application fully in Haskell. I have 3 logical packages:
A backend, using servant
A frontend, using reflex, reflex-dom and servant-reflex
A shared package defining the Servant API for communication between the 2 and some data types for that API to use.
That last package is giving me trouble. I don't know how to structure the project so the other 2 packages can use it. I see 2 options at the moment:
Each package has its own stack file and git repository. Import the shared package using an extra-deps git link. The problem with this approach is it means I have to push any change to the shared package to GitHub before I can test it out with the other packages. Also I'd have to build everything separately.
Use a single repository with a single stack.yml file. I'd prefer this, since it keeps everything together and also assures all packages are using the same resolver. In this case I would list all the packages in the packages: option. However, the client needs to be compiled with GHCJS, not GHC, and I don't see an option in the documentation to override the compiler for 1 specific package.
Is there a way to make option 2 work? Or is there a better way to do this?
The recommended approach is to have two stack project files (e.g. stack-frontend.yaml using GHCJS and stack-backend.yaml using GHC), and then use the --stack-yaml argument to switch between them (e.g. use stack --stack-yaml=stack-frontend.yaml build to build the frontend, and stack --stack-yaml=stack-backend.yaml build to build the backend). Both stack-*.yaml files can include the shared servant API.
Related
I am testing hint library which does magic thing - evaluates Haskell code in runtime! The library is working almost as expected, but following deviation raised a question in my head.
Let's say there is a typical new stack project from a template with app and library. Dependence of app on library is described same way as any other package (base, text, lens, etc), but Haskell script file cannot import modules residing in the library of the same stack package, meanwhile modules from hackage libraries such as process library are resolved without any issue for the script.
Module required inside a script becomes available once I extract it into a stack sub packages.
So, is there a linking trick voiding extra stack sub package?
link the issue on Github
Try running stack install to install your package into the package database.
I've created a nimble library package as per the documentation. When I try to build it using nimble build I get the following error.
Error: Nothing to build. Did you specify a module to build using the bin key in your .nimble file?
I can do this and it does fix the error but according to the documentation adding the bin key to the .nimble file turns my package into a binary package.
Other things I have tried:
Use nimble install: This does not appear to verify that my code will actually compile and will happily install anything to the local package directory (I added a C# class to my .nim file, for example, and it was successfully installed).
Use nimble c: This works but I have to pass in the path to the nim file I want to compile and the binDir entry in the .nimble file is ignored resulting in the output being placed in the same directory as the file being built. This complicates the development cycle because I have to manually clean up after the compiler.
Use the compiler directly. This is pretty much the same as the previous option with the same flaws.
I guess I could also create a separate .nim file and import my library after it is installed but this is a big overhead for just wanting to verify that a package in the early stages of development will actually compile.
I just want to be able to verify that the source code in my library package is syntactically correct and will compile. How is this meant to be done for library packages?
From your provided link to the nimble package manager documentation I have the feeling that
https://github.com/nim-lang/nimble#tests
is what you are looking for. But I have never used the test command, so I am not sure. I do my test manually still, I read the nimble docs maybe 4 years ago and can not really remember. And currently there is much package manager related work going on, I heard there is a new, alternative package manager called nimph, and from a forum thread I think I read something that nimble is going to change and improve also. Maybe you should consider subscribing to the Nim forum, that is the place where the bright Nim devs are. Well, at least a few of them.
I have a locally authored Haskell project, which produces both:
a binary executable, and
several new Haskell modules, which I'd like made accessible to my other, Haskell based, executables.
After:
stack build
stack install
I'm finding that:
the binary executable (#1, above) runs just fine from any directory.
But, the new Haskell modules (#2, above) are only found when I'm running from within my project directory! (That is, for any executable other than #1, above.)
I need to be able to find the new modules from anywhere.
How can I achieve this?
Each stack project is in its own sandbox, so the compiled modules can only be used within that project. Compiled dependencies (which come from a stackage snapshot) sometimes get shared between projects.
Note that you can list a relative path in the packages list, and point to this package. It will get built again, but it can be directly used in another project this way. Why the extra building? Stack has a different model of projects than cabal-install - it does not allow mutations to the package DB to affect how your other projects build.
One option for sharing such a package is to have it in a git repo and use https://docs.haskellstack.org/en/stable/custom_snapshot/ , but that stuff is still a bit new.
In a node.js project, I'm using Go for a critical part of it that node isn't adequate enough to handle. I want to split the Go code into a sockets package and a main package, with sockets containing required structs/interfaces for the main package to run. The problem I'm having is that from what I can gather from Go's documentation, I can only use external packages like sockets remotely from github/gopkg. I don't want to split the repository for the project into one containing the Go code and one containing node's. How can I make the sockets package available for main to import locally while making it possible to rebuild the binaries for the two packages if any updates to their source code are made?
Edit: importing the packages is no longer an issue, but rebuilding packages on update still remains
It happens the same to my team too and we end up using vendor it's pretty easy to manage all the external packages. So, whoever checkout your repo will have all the packages inside vendor.
Understanding and using the vendor folder
And Please refer this site lots of other option out there too:
Golang Package Management Tools
I'm writing a library and a project that uses the library. It's common with Stack to put both in the same folder and maintain a multi-package project, but I want to have two separate projects instead. Stack has external dependencies for this, but they are specified by locations and the projects runs on multiple machines, so it's inconvenient to specify paths (unless it's possible to have nested Stack projects, but this kinds defeats the purpose of having separate packages). I also don't want to use git locations, because it feels burdensome to explicitly specify commits (or maybe this is not necessary?), and don't want to pack the repository in an archive and then download it each time I change something.
Ideally, I would like to be able to install the library on a machine and then reference it somehow in stack.yaml by its name, not location. Is it possible to do that? If not, is there a convenient way to maintain two separate but related packages?
I ended up using git submodules as jonrsharpe suggested. Works good so far.