I committed a change to Haskell's opaleye project that I need for a project I am working on. The change is in version 0.6.7003.1, which has not propagated to the nixos repository yet (nixos.org shows its current version to be 0.6.7001.0).
Since this needed dependency differs from the the resolver's LTS version, I have marked the extra dependency in stack.yaml:
packages:
- git#github.com:tomjaguarpaw/haskell-opaleye.git
- commit: cf3296c5ffef58d36dd6b386ae53dff519ee47e9
I have also marked this version in the build-depends of my project.cabal file:
build-depends: opaleye >= 0.6.7003.1 && < 1
When I then attempted to build, I got the following error:
$ stack build
Error: While constructing the build plan, the following exceptions were encountered:
In the dependencies for taskmaster-0.1.0.0:
opaleye must match >=0.6.7003.1 && <1, but the stack configuration has no specified version (latest matching version is 0.6.7003.1)
needed since taskmaster is a build target.
Some different approaches to resolving this:
* Consider trying 'stack solver', which uses the cabal-install solver to attempt to find some working build configuration. This can be convenient when dealing with many
complicated constraint errors, but results may be unpredictable.
* Recommended action: try adding the following to your extra-deps in /home/matthew/backup/taskmaster/taskmaster/stack.yaml:
opaleye-0.6.7003.1#sha256:914ac99c6f7ceea050df843ac31c33be0f6340bc0f05753c8fdfc18074fa9e5b
Plan construction failed.
(I do not understand where this long (>40 char) sha256 hash comes from).
I followed the advice and added the following to my stack.yaml.
extra-deps:
- opaleye-0.6.7003.1#sha256:914ac99c6f7ceea050df843ac31c33be0f6340bc0f05753c8fdfc18074fa9e5b
When I run $ stack build to build my project, the compiler attempts to build without showing any dependency errors. However, it strikes a type error that it would not if it were using the version of Opaleye containing my change. And, when I run $ stack ghci and import a relevant opaleye module, my change is not present. It appears that somehow stack is still using an older opaleye version. How can I get stack to use the more recent version of opaleye containing my change?
My attempts seem to have exhausted the options mentioned in the haskell-stack documentation.
The hackage option is usually better than the github extra-dep.
The correct syntax for what you initially tried would be
extra-deps:
- git: https://github.com/tomjaguarpaw/haskell-opaleye.git
commit: cf3296c5ffef58d36dd6b386ae53dff519ee47e9
and the github: tomjaguarpaw/haskell-opaleye version is just a shortcut.
The sha256 hash is the sha256sum of the cabal file corresponding to that version (and revision) of opaleye.
Given that version of opaleye is already on hackage, you should just be able to add the line suggested by stack. You may wish to try a stack clean after you make the change (though it shouldn't be necessary).
If you present more information, I'll update this answer.
It turned out that stack's extra-deps suggestion was incorrect. I noticed an alternative format under this stack github issue, gave it a try, and it happened to work for me. The working extra-deps format is listed below.
extra-deps:
- github: tomjaguarpaw/haskell-opaleye
commit: cf3296c5ffef58d36dd6b386ae53dff519ee47e9
Related
I need a pre build project and I need a version of protoc-gen-go v1.25.0-devel but I am unable to find command etc to install It , till now I tried to do something like this :
go get -u google.golang.org/protobuf/cmd/protoc-gen-go#v1.25.0-devel
and I am getting this ERROR invalid version: unknown revision cmd/protoc-gen-go/v1.25.0-devel
Is there any way to get this version ?
If you're following this post to create a sample service, you don't need the specific version 1.25.0-devel that appears in the generated files. You should use the latest stable version (currently v1.26.0). Since it is an minor version upgrade, there should be no breaking changes between versions. One thing that you may need to make the examples in the post to work is that you should set the package for the generated code. You can set it in the .proto file as an option, for example option go_package = grpc-example/generated/protos/calc or as a command line argument for the protoc command, for example protoc ...OTHER_OPTS --go_opt=Mprotos/calc.proto=grpc-example/generated/protos/calc.
If you are sure that you absolutely need the specific version v1.25.0-devel you can install the plugin pointing to a specific commit (as that version is not currently available as a tag/branch name). If you're using go 1.16.x you can use go install google.golang.org/grpc/cmd/protoc-gen-go-grpc#a9513eb pointing at this commit. For older go versions, use go get
I am trying to wrap my head around go modules. This is what I have done so far.
Created a simple module and published it as 0.0.1 on github.
Referenced the above mentioned module in a separate go project and used it.
so far it works fine. Now I update the initial module to 0.0.2 and publish it as a release on github. Now when I try go get <published module> it still seems to fetch the original 0.0.1 version and run it. I also deleted all references to 0.0.1 including in go.mod and go.sum and run go get and it still fetches the original 0.0.1 version instead of 0.0.2.
I also tried publishing a major version 1.0.0 and tried to use it, but its still fetching the older 0.0.1 version. I thought it will automatically fetch the latest version and use that.
My go.mod file also shows the following even for the major version
require github.com/user/module v0.0.0-20210223020204-1b5fb712826f // indirect
I feel there could be something wrong in the way its being published on git. Any help, anyone.
It looks like the comments already highlighted the required steps to take, but to capture the information in an answer, here is the relevant snippet from go help get
The -u flag instructs get to use the network to update the named packages
and their dependencies. By default, get uses the network to check out
missing packages but does not use it to look for updates to existing packages.
Basically, go get will only fetch the versions locked in your go.{mod,sum} files and you need to explicitly ask for updates using one of:
# upgrade to the latest release
go get -u github.com/user/module
# upgrade to a specific version
go get github.com/user/module#2.0.0
# use the `latest` version alias
go get github.com/user/module#latest
I'm trying to install the ghc-mod library on Windows. Using stack install ghc-mod shows this lengthy error message:
Error: While constructing the build plan, the following exceptions were encountered:
In the dependencies for ghc-mod-5.8.0.0:
Cabal-2.4.1.0 from stack configuration does not match >=1.18 && <1.25 (latest matching version is 1.24.2.0)
base-4.12.0.0 from stack configuration does not match >=4.6.0.1 && <4.10 (latest matching version is 4.9.1.0)
cabal-helper must match <0.8 && >=0.7.3.0, but the stack configuration has no specified version (latest matching
version is 0.7.3.0)
djinn-ghc must match <0.1 && >=0.0.2.2, but the stack configuration has no specified version (latest matching
version is 0.0.2.3)
extra-1.6.17 from stack configuration does not match <1.6 && >=1.4 (latest matching version is 1.5.3)
ghc-8.6.5 from stack configuration does not match >=7.6 && <8.2
ghc-syb-utils must match <0.3 && >=0.2.3, but the stack configuration has no specified version (latest matching
version is 0.2.3.3)
haskell-src-exts-1.20.3 from stack configuration does not match <1.20 && >=1.18 (latest matching version is 1.19.1) hlint-2.1.11 from stack configuration does not match <2.1 && >=2.0.8 (latest matching version is 2.0.15)
monad-journal-0.8.1 from stack configuration does not match <0.8 && >=0.4 (latest matching version is 0.7.2)
optparse-applicative-0.14.3.0 from stack configuration does not match >=0.13.0.0 && <0.14 (latest matching version
is 0.13.2.0)
temporary-1.3 from stack configuration does not match <1.3 && >=1.2.0.3 (latest matching version is 1.2.1.1)
needed since ghc-mod is a build target.
Some different approaches to resolving this:
* Build requires unattainable version of base. Since base is a part of GHC, you most likely need to use a different
GHC version with the matching base.
Apparently, I need to change the version of ghc, but my version is higher than the one required, so updating doesn't help. Should I downgrade? How to do it without messing up the rest of my ghc ecosystem?
Using cabal to install it gives similar results.
Sorry, but you can't do this unless you are willing to downgrade to GHC 8.0. Note in the dependencies list it says ghc (>=7.6 && <8.2). There is no GHC 8.1 (odd numbers are for testing), so its back to GHC 8.0.
Stackage provides a curated list of package versions which are known to compile together, along with a version of GHC. Each Long Term Support (LTS) is a specific set of these versions. As you can see from the list posted by Damián Rafael Lattenero that means going back to LTS-9.21.
The problem is that ghc-mod uses GHC as a library as well as a compiler, so it is very sensitive to the version, and you have to use the same version of the compiler for both ghc-mod and the software you are developing; having got a working version of ghc-mod you can't just switch to a later version of GHC for your own program.
Assuming you still want to do this, get stack installed. Then edit your ~/.stack/config.yaml file (on Windows type stack path --stack-root to find where this is stored). Change it to say resolver: lts-9.21. Then say stack install ghc-mod.
In stackage you can find all the LTS versions and all the possible releases you can download:
and here is the list of all the dependencies you need for ghc-mod:
You need to check that you don't have any outdated or unmatched.
Just got started with Nix (version 2.2.1), and while installing darcs (version 2.14.1) i encountered my first problem: I get the following error message (preceded by the callstack):
Setup: Encountered missing dependencies:
base >=4.9 && <4.12,
network >=2.6 && <2.8,
stm >=2.1 && <2.5,
zip-archive ==0.3.*
I have the haskell tool stack installed as well as a global ghc (though both should not be needed to build darcs i think).
I also had no problem with installing darcs with 'apt'
Am i making a classic nix beginner mistake or whats going on here?
Nix is very different from package managers like 'apt'. Derivations (which are like packages) are designed to be built in an isolated environment, where the derivation is responsible for providing its own dependencies by referencing other derivations. Because of this, you do not need to explicitly install anything in order to build a package.
Note also that although Nixpkgs uses the Cabal library to build Haskell packages, installing a package via Nix is quite different from installing with cabal-install. In fact it is closer to Stack, because Nixpkgs defines its haskellPackages based on stackage and it avoids cabal-style dependency resolution. It does however let you use the Cabal solver to check whether the dependencies match the versions specified in the cabal files. This check can be disabled using the doJailbreak function in Nixpkgs.
I don't think we need to get into the details of Haskell packaging in Nixpkgs though, because you should be able to get a pre-built darcs from the nixos-18.09 channel. The Nix expression from the nixos-unstable produces exactly your error message.
I recommend you to use the latest release channel, nixos-18.09, because nixos-unstable will break regularly. See the Nix manual for changing your channel configuration.
I'd made a package that include 2 components according to --component-plist file. on the plist file I've added the following flag to prevent downgrade :
BundleIsVersionChecked: Don't install bundle if newer version on disk? (bool)
when I perform downgrade scenario, I get the following message :
Sep 15 11:42:49 os-x-10 installd[284]: PackageKit: Skipping component \
"com.my.driverAE21E" (<current_version>) because the version \
<new_version> is already installed at <my_component>
This is expected, but unfortunately, the installation goes on, and the other component is being properly installed, and so does the preinstall and postintsall scripts - so I get a mixture of both versions.
Is there any way to enforce component version validation prior to any attempt to actually install them, and stop the installation process in case the validation wasn't pass.
UPDATE :
Another approach that can help me is to prevent the running of preinstall and postinstall scripts in case an attempt to downgrade is made.
I've seen reference to unanswered question about this issue here.
What you need to do is add version-check to your distribution.xml for product archive, and then perform whatever check you want in JavaScript code. This will allow you to prevent installation from starting as early as possible by returning false from the check function. Can't give you an example as I never did custom version check myself, but using my.target.receiptForIdentifier() and system.compareVersions() should get you going.
More info on the matter: https://developer.apple.com/reference/installerjs (follow "Distribution Definition XML Schema Reference" link there for distribution.xml description).