After following the instructions on the QuickStart, I'm seeing some errors in Yesod when bringing up a webpage. The errors end in:
...
cannot satisfy -package-id wai-extra-1.3.4.6-62543d69d10941dae1d9b206c3eb3067:
wai-extra-1.3.4.6-62543d69d10941dae1d9b206c3eb3067 is unusable due to missing or recursive dependencies:
blaze-builder-conduit-1.0.0-1053545317cd68e3d51439dd9a0e622d zlib-conduit-1.0.0-b51dc7daf506ea4c5ecd031c5101d96a
(use -v for more information)
Build failure, pausing...
Hopefully related, the referenced tutorial has me run
cabal-dev install
on a fresh Yesod project, however that also gives me errors:
...
[1 of 1] Compiling Control.Monad.Logger ( Control/Monad/Logger.hs, dist/build/Control/Monad/Logger.o )
Control/Monad/Logger.hs:63:39:
Module System.Log.FastLogger' does not exportpushLogStr'
Control/Monad/Logger.hs:63:72:
Module System.Log.FastLogger' does not exportLoggerSet'
Control/Monad/Logger.hs:63:83:
Module System.Log.FastLogger' does not exportnewLoggerSet'
Control/Monad/Logger.hs:63:97:
Module System.Log.FastLogger' does not exportdefaultBufSize'
Failed to install monad-logger-0.3.3.0
...
On this later set of errors, I came across a page suggesting the issue has been fixed (SO won't let me post more than 2 links, but Google the error and it comes right up).
Any ideas?
Thanks in advance!
I'd suggest using cabal sandbox for each Yesod project, rather than installing the Yesod platform as part of your system libraries. Think of a cabal sandbox as a localized collection of Haskell packages in a single project, so you could have different versions of a package, say Data.Text, in 2 different cabal sandboxes. Using cabal sandbox takes longer time for compilation but it makes things simpler for dependency resolution (read more here: (read more here: http://coldwa.st/e/blog/2013-08-20-Cabal-sandbox.html). cabal sandbox requires a cabal version of at least 1.18 if I'm not mistaken.
Alright, enough of the talk. Let's get started.
To get the latest cabal, it's easier if you have cabal installed through a package manager, even if the package manager installs a cabal without cabal sandbox. Since you are on Ubuntu, just:
sudo apt-get install cabal
Once you have some version of cabal installed, run:
cabal sandbox
If you see something along the lines of this:
cabal: Please specify a subcommand (see 'help sandbox')
Then congratulations, the version of cabal that you have supports cabal sandbox, just move on Once you have a Cabal with cabal sandbox section of the answer.
If instead you see something like:
cabal: unrecognised command: sandbox (try --help)
Then you will need a more modern version of cabal. Simply clone the cabal repository on github:
git clone https://github.com/haskell/cabal.git
Go to the directory, and checkout the branch Cabal-v1.18.1.2, like so:
git checkout Cabal-v1.18.1.2
Then execute:
cabal install Cabal/ cabal-install/
This should install cabal in the $HOME/.cabal/bin folder. Be sure to prepend $HOME/.cabal/bin to your PATH environment variable, before the folder where the system's cabal is located.
Once you have a Cabal with cabal sandbox
Based on what I read from the Yesod quick start guide, you will want to install the yesod-bin package. It's hackage page is here. Basically, yesod-bin provides you with a yesod binary that allows you to initialize a scaffolded site. The latest version of yesod-bin is 1.2.5.6, and that's what we're going to install.
Create a directory named yesod-bin:
mkdir yesod-bin
Go into that directory, and set up a cabal sandbox in that it, like so:
cabal sandbox init
Fetch the latest package list from hackage using:
cabal update
Now, we are going to install the latest version of yesod-bin, 1.2.5.6, in a cabal sandbox. However, yesod-bin has a dependency on the mmorph package, which defaults to install version 1.01, and trying to install mmorph-1.01 will result in an error message like the following:
src/Control/Monad/Morph.hs:76:8:
Could not find module `Control.Applicative.Backwards'
Use -v to see a list of the files searched for.
Failed to install mmorph-1.0.1
cabal: Error: some packages failed to install:
mmorph-1.0.1 failed during the building phase. The exception was:
ExitFailure 1
and installing yesod-bin without specifiy the mmorph package version defaults to installing mmorph-1.0.1, resulting in the following error:
cabal: Error: some packages failed to install:
base64-conduit-1.0.0 depends on mmorph-1.0.1 which failed to install.
blaze-builder-conduit-1.0.0 depends on mmorph-1.0.1 which failed to install.
conduit-1.0.10 depends on mmorph-1.0.1 which failed to install.
http-client-conduit-0.2.0.1 depends on mmorph-1.0.1 which failed to install.
http-conduit-2.0.0.3 depends on mmorph-1.0.1 which failed to install.
http-reverse-proxy-0.3.0 depends on mmorph-1.0.1 which failed to install.
mmorph-1.0.1 failed during the building phase. The exception was:
ExitFailure 1
network-conduit-1.0.1 depends on mmorph-1.0.1 which failed to install.
project-template-0.1.3.2 depends on mmorph-1.0.1 which failed to install.
resourcet-0.4.10 depends on mmorph-1.0.1 which failed to install.
wai-2.0.0 depends on mmorph-1.0.1 which failed to install.
wai-logger-2.1.1 depends on mmorph-1.0.1 which failed to install.
warp-2.0.2 depends on mmorph-1.0.1 which failed to install.
yaml-0.8.5.3 depends on mmorph-1.0.1 which failed to install.
yesod-bin-1.2.5.6 depends on mmorph-1.0.1 which failed to install.
which seems to be related to these 2 issues in the mmorph github repo:
https://github.com/Gabriel439/Haskell-MMorph-Library/issues/8
https://github.com/Gabriel439/Haskell-MMorph-Library/pull/10
However, mmorph version 1.0.0 works fine. As such, we will have to specify the version of mmorph to be 1.0.0 when we install yesod-bin, like this:
cabal install mmorph-1.0.0 yesod-bin-1.2.5.6
This will take quite some time. cabal sandbox creates a directory named .cabal-sandbox inside the yesod-bin directory, and the yesod binary (along with several other binaries from the yesod-bin package) can be found in the .cabal-sandbox/bin folder. Simply add that folder into your PATH, and you should be able to do the yesod init and yesod devel as seen at the end of the quick start.
As an quick update to #yanhan great answer, since I have tried to follow his guidelines on Ubuntu 14.04 LTS and get stuck a bit.
If you don't have cabal executable preinstalled, you can also do:
git clone https://github.com/haskell/cabal.git
Then of course:
git checkout Cabal-v1.20.0.2
And then you can use the bootstrap.sh script to install cabal executable and Cabal package:
cd cabal-install && ./bootstrap.sh
It will take some time, but soon after you can check the version of newly installed cabal executable:
$HOME/.cabal/bin/cabal --version
Related
I have an installation of Jenkins on Azure and wish to build a c++ project using Conan. Many examples show the following pipeline command to initiate Conan:
def conanClient = Artifactory.newConanClient()
however this throws an error:
sh: 1: conan: not found ERROR: Couldn't execute Conan task.
RuntimeException: Conan build failed with exit code 127
I assumed the newConanClient() would install Conan but that is not the case as verified by:
sh 'conan -v' resulting in conan: not found
From the JFrog documentation you would think there shouldn't be any problems as they say:
There is no need for any special setup for it, just install Conan and
your build tools in the Jenkins machine and call the needed Conan
commands.
https://docs.conan.io/en/latest/integrations/ci/jenkins.html?highlight=jenkins
So how does one "just install Conan" in Jenkins?
From the Documentation:
Conan can be installed in many Operating Systems. It has been extensively
used and tested in Windows, Linux (different distros), OSX, and is also
actively used in FreeBSD and Solaris SunOS. There are also several
additional operating systems on which it has been reported to work.
Based on your OS, you can install from here. newConanClient() method is part of the Artifactory plugin for Jenkins but doesn't install Conan
Now you can verify the installation
conan -v
and further can execute commands in Jenkins pipeline
sh 'conan build .'
I am trying to install psycopg2-binary into my Django project. I am using a virtual environment and the command I'm running is
pip install psycopg2-binary
However, I'm getting a massive error message, the gist of it is this:
Error: pg_config executable not found.
pg_config is required to build psycopg2 from source. Please add the directory
containing pg_config to the $PATH or specify the full executable path with the
option:
python setup.py build_ext --pg-config /path/to/pg_config build ...
or with the pg_config option in 'setup.cfg'.
If you prefer to avoid building psycopg2 from source, please install the PyPI
'psycopg2-binary' package instead.
But, hey, I'm installing exactly 'psycopg2-binary'
Why am I getting all this mess?
Pip cannot find you processor+OS at https://pypi.org/project/psycopg2-binary/2.9.2/#files so it tried to install from sources (the last file at the page) and failed.
Compiling from sources is currently the only way. If you can donate some spare processor cycles to the Psycopg2 authors they perhaps could start compiling and publishing wheels for OSX on M1.
Following these instructions to install the DataStax C++ Driver on MacOS High Sierra, as a pre-requisite to installing the DataStax PHP Driver for Cassandra.
Everything runs great until I get to the line "make install" in the "Building and installing the C/C++ driver" section. That's where I get the message: "make: *** No rule to make target `install'. Stop."
Can someone help me get past this step?
** SOLVED ** a friend helped me stumble across the solution. Two things to remember when installing on MacOS High Sierra:
1.) You need to run the install of cpp-driver (which isn't a step in the DataStax instructions referenced in the question) and then
2.) You have to fully qualify the cmake .. command to point to the OpenSSL install.
Here are the amended instructions that worked for me:
# Datastax C++ driver dependencies
brew install libuv cmake
brew install openssl
brew link --force openssl
# Install git if you dont have it
brew install git
# Retrieve the cpp
git clone https://github.com/datastax/cpp-driver.git --depth=1
mkdir cpp-driver/build
cd cpp-driver/build
# Build with qualified path to OpenSSL location
cmake -DOPENSSL_ROOT_DIR=/usr/local/opt/openssl/ -DOPENSSL_LIBRARIES=/usr/local/opt/openssl/lib ..
make
make install
# Install pecl driver
pecl install cassandra
Once that's complete you should be good to go.
We are using Visual Studio Team Services for build and deployment of several sites. Some .NET and some are not. All working fine when using the hosted agent. Due to performance issues and long queue times for the hosted agent we need to use our own build agent.
Here comes the problem:
When running the VSTS builds we get an error when running bower:
******************************************************************************
Starting: bower install
******************************************************************************
C:\Program Files (x86)\nodejs\npm.cmd install -g bower
C:\Windows\ServiceProfiles\NetworkService\AppData\Roaming\npm\bower -> C:\Windows\ServiceProfiles\NetworkService\AppData\Roaming\npm\node_modules\bower\bin\bower
bower#1.7.9 C:\Windows\ServiceProfiles\NetworkService\AppData\Roaming\npm\node_modules\bower
Not found bower: null
******************************************************************************
Finishing: bower install
******************************************************************************
The problem is that bower is actually in that location:
And here are the actual bower build step:
How can we fix this Not found bower: null error?
There are known issues with tools installed into profile folders it has to do with permissions. It's easier to install the tool from an administrative console with the -g parameter. And ensure that the central NPM version is added to the service or system's %path% environment variable.
Or pass in a specific location by adding additional parameters to the call to npm: npm install --prefix "$(Agent.WorkFolder)" Bower Then specify the same location in the Advanced section of the Bower task.
Bower CLI location: $(Agent.WorkFolder)\node_modules\
(You'd need to check the exact location the package is installed to, I'm slightly guessing at the moment ;)).
I'm trying with little success to build and install conda packages in for envs in the Anaconda python distribution. Right now I'm trying to build a package for flask-wtf. I copied the .bat, .sh, and .yaml recipe files from Continuum IO's recipe. The files are in a directory named flask-wtf on my desktop, and I ran conda build flask-wtf on it. It returned the message: Error: No packages found matching: wtforms. I do not have wtforms installed anywhere, so now I have two questions:
1) If I install wtforms do I have to install it globally, or can I keep it in the relevant conda env?
2) If I install wtforms from a tarball do I have to keep that tarball file around for later installs into other envs?
Thanks for your help and clarification!
The only way that conda build will see dependencies is if they also exist as conda packages. So you need to build the conda package for wtforms as well. Fortunately, the recipe for this exists in the conda-recipes as well, so you can just clone that repo and do
conda build wtforms
conda build flask
This works because conda is able to find the packages that it has already built. To make sure that they don't get lost if you delete the build directory, it's recommended to upload your packages to Binstar. If you do that and conda install binstar, after you build, it will ask you if you want to upload the package to binstar. If you do that, and also add your Binstar repo to your .condarc, those packages will always be available for you to conda install.