I have gone through the following steps:
$ mkdir mongoEg
$ cd mongoEg
$ cabal init
...
Configured to run as an executable. I add mongodb to the build-depends list. I make a dummy Main.hs file and put a basic hello world in there. I then do
$ cabal sandbox init
$ cabal install --only-dependencies
Which responds with:
Resolving dependencies...
cabal: Could not resolve dependencies:
trying: monogEg-0.1.0.0 (user goal)
next goal: mongodb (dependency of monogEg-0.1.0.0)
Dependency tree exhaustively searched.
Note: when using a sandbox, all packages are required to have consistent
dependencies. Try reinstalling/unregistering the offending packages or
recreating the sandbox.
I read up on other problems people are having, and remove ~/.ghc, remove my mongoEg directory, and repeat to get the same results. I try to run through the analogous steps at http://howistart.org/posts/haskell/1 and find that everything works just fine.
I then guess that something is wrong with the mongodb package itself. I seem to be able to cabal install mongodb in a global environment and use it outside of a sandbox without any issue. So, why wont cabal sandboxes play with the mongodb package?
See this gist for details: https://gist.github.com/anonymous/e5a548cf7d9ec59bea31
After looking here
Cabal configure in a sandbox complains "At least the following dependencies are missing" on installed packages
I saw that the answer states that package names are case sensitive. So I tried changing mongodb to the way MongoDB spells it, namely MongoDB. This did not work, so I tried changing it to mongoDB, and finally there was joy.
So even though I can do cabal install mongodb I can't use that same spelling to install it from within a .cabal file, which is, obviously, completely stupid. I'm sure I'll find the right place to channel my rage about this kind of flagrant violation of the principle of least surprise, but for now I can say that to newcomers it is most needlessly confusing.
Related
This question is somewhat similar to the one here, but I cannot make it work.
So suppose that I have a set of packages (say 2) to install and I want to use pipenv. If I do pipenv install on the directory with a suitable Pipfile the installation fails because there is some metadata issue when installing one of the libraries (say libX) contained in install_requirements of one of the packages. It seems that the problem can be fixed by downgrading the version of setuptools to <=58.0.0.
OK. Now, if I first install that version of setuptools<=58.0.0 in the venv and then install my packages, everything works fine. The issue is that the Pipenvfile does not respect the order when installing, so something like
[packages]
setuptools = "<=58.0.0"
pckg1 = {<github path 1>}
pckg2 = {<github path 2>}
is not ensured to work. Also, by default the seed packages added to the venv include setuptools==65.6.3.
So the idea is to be able to restrict the version of setuptools that is used to check the metadata of the libraries in libX, to mimic the above scenario in which setuptools was installed first. Is there a way to do that?
I have tried placing setuptools<=58.0.0 at the top of the requirements.txt that defines the install_requirements of the problematic package, but it does not work.
If have also tried to fix or restrict the version of libX contained in that requirements.txt file but, surprisingly, pipenvdoes not seem to care: a verbose install shows that it keeps downgrading libX well below the restriction - "using cached libX-vX.X.X"- until it uses a version for which the metadata generation fails (why on earth does it do that, even if I call it with pipenv --clear install?).
I am a bit lost about what could be the best solution here. Any help would be very appreciated.
I am trying to update an old racket package I had written ages ago to run on the new racket. I found the documentation extremely confusing and seemingly broke everything. Can you please suggest how things can be resolved?
While trying to run raco pkg install {path/to/package} I got an error saying my package was trying to find the old Racket 6.4 installation and since I have updated my operating system since then it didn't find it. I searched in that directory and could only find such references in the compiled/ folder. I skimmed the raco documentation and saw that raco setup --clean would remove that compiled folder. However, I thought it would be context specific: working on just the package who's directory I was in. That appears to not be the case. Now raco pkg doesn't even exist as a sub-command of raco!
How can I restore it and get back to trying to update my package so that it can be installed on the latest racket?
When you run raco, it works on the installation that it's a part of. So, for instance, if you have two copies of racket installed at /Users/clements/racket1/racket and /Users/clements/racket2/racket, then if I run the raco that's a part of the racket1 installation, I'll be updating the packages that are associated with the racket1 installation.
Sounds sensible, but I've messed this up myself, many times: depending on how your path is set up, the command raco may refer to either the racket1 or the racket2 installation. The problem here isn't really with racket, it's with the idea of paths, and how easy it is to mess things up when you have two installations containing the same binaries.
(And, of course, apologies if I'm misunderstanding your problem!)
I have a Python library (https://github.com/jcrozum/PyStableMotifs) that I want to publish on PyPI. It depends on another library (https://github.com/hklarner/PyBoolNet) that I do not control and that is only available on GitHub, and in particular, it is not available on PyPI. My setup.py looks like this:
from setuptools import
setup(
... <other metadata> ...,
install_requires=[
'PyBoolNet # git+https://github.com/hklarner/PyBoolNet#2.3.0',
... <other packages> ...
]
)
Running pip install git+https://github.com/jcrozum/PyStableMotifs works perfectly, but I can't upload this to PyPI because of the following error from twine:
Invalid value for requires_dist. Error: Can't have direct dependency: 'PyBoolNet # git+https://github.com/hklarner/PyBoolNet#2.3.0'
My understanding is that direct links are forbidden by PyPI for security reasons. Nonetheless, PyBoolNet is a hard requirement for PyStableMotifs. What do I do? Give up on PyPI?
I just want pip install PyStableMotifs to work for my users. Ideally, this command should install the dependencies and I should not have to maintain two versions of setup.py.
Failing that, I have considered creating a "dummy" package on PyPI directing users to install using the command pip install git+https://github.com/jcrozum/PyStableMotifs. Is this a bad idea (or even possible)?
Are there already established best practices for this situation or other common workarounds?
EDIT:
For now, I have a clunky and totally unsatisfying workaround. I'm keeping two versions; a GitHub version that works perfectly, and a PyPI version that has the PyBoolNet requirement removed. If the user tries to import PyStableMotifs without PyBoolNet installed, an error message is shown that has install instructions for PyBoolNet. This is far from ideal in my mind, but it will have to do until I can find a better solution or until PyPI fixes this bug (or removes this feature, depending on who you ask).
My recommendation would be to get rid of the direct URL in install_requires, and tell your users where they can find that dependency PyBoolNet since it is not on PyPI. Don't force them on a specific installation method, but show them an example.
Maybe simply tell your users something like:
This project depends on PyBoolNet, which is not available on PyPI. One place where you can find it is at: https://github.com/hklarner/PyBoolNet.
One way to install PyStableMotifs as well as its dependency PyBoolNet is to run the following command:
python -m pip install 'git+https://github.com/hklarner/PyBoolNet#2.3.0#egg=PyBoolNet' PyStableMotifs
You could additionnally prepare a requirements.txt file and tell your users:
Install with the following command:
python -m pip install --requirement https://raw.githubusercontent.com/jcrozum/PyStableMotifs/master/requirements.txt
The content of requirements.txt could be something like:
git+https://github.com/hklarner/PyBoolNet#2.3.0#egg=PyBoolNet
PyStableMotifs
But in the end, you should really let your users choose how to install that dependency. Your project only need to declare that it depends on that library but not how to install it.
Debian Jessie, as well as sid, have a mercurial-git package which contains the hg-git plugin. However, this package was (auto-)removed from Debian Stretch to to a release-critical bug.
But - I need it installed and running. Surely this should be possible, right?
Well, I followed the installation instructions on the plugin page:
I ran apt-get install python-setuptools python-setuptools-git python4-setuptools python3-setuptools-git
I ran easy_install hg-git and it seemed to work
But still, when I run various mercurial operations I get, as the first line, the error message:
*** failed to import extension hgext.git: No module named git
(regardless of whether I'm doing anything git-related or not.)
My questions:
Why is this happening?
What do I need to do in order to make the error message go away while having hggit working?
Now,
How do I correctly install dulwich to get hg-git working on Windows?
Apparently, that critical bug doesn't manifest always (and perhaps only under very specific circumstances), so you can try installing the Debian sid version of the mercurial-git package (that is, version 0.8.11-1 at the time of writing). There's a SuperUser question about how to do this:
https://linuxaria.com/howto/how-to-install-a-single-package-from-debian-sid-or-debian-testing
my personal opinion in this case is to simply install the .deb file, which you can get from here (it's not platform-specific; at the link you'll need to choose a mirror.) That makes the error message go away, at least assuming you have:
[extensions]
hgext.bookmarks =
hggit =
in your ~/.hgrc file.
I followed the instructions in GStreamer Plugin Writer's Guide (1.7.1.1):
http://gstreamer.freedesktop.org/data/doc/gstreamer/head/pwg/html/index.html
in order to build a new gstreamer plugin. Basically I ran make_element and then edited Makefile.am as described. Amazingly make and make install worked and I ended up with:
/usr/local/lib/gstreamer-1.0/libgstframe_grabber.la
/usr/local/lib/gstreamer-1.0/libgstframe_grabber.so
As I understand it, gst-inspect should find this plugin automatically. The guide says that /usr/local/lib/gstreamer-1.0 needs to be added to GST_PLUGIN_PATH in order for plugins in this directory to be found. Another document states that this directory is searched automatically. I tried with and without the environment variable, but no luck.
Now I should say that I have just started to use gstreamer and I am suffering from total information overload. I have read so many documents, yet I don't even know whether I am building a gstreamer1.0 or a gstreamer0.10 plugin (I think the guide is for gstreamer1.0, since the guide's version is 1.7.1.1 but can't be sure).
Can anybody give me a clue here ?
There are many possible reasons that can cause this issue.
First, check if your plugin is blacklisted by command gst-inspect-1.0 -b.
If your plugin show up here, that means it is really blacklisted.
In that case, delete directory ~/.cache/ and then run gst-inpect-1.0 again.
This will force GStreamer to re-scan plugins list. If the reason of blacklist is not solved yet, gst-inpect will probably print out the reason here for you.
Another possible reason (but unlikely happens) is setting GST_REGISTRY_UPDATE as no, which will force GStreamer NOT to rescan the plugin directory, thus not found new plugin
P/s: The guide is for GStreamer 1.0
If you've tried removing your plugin from the blacklist and it still doesn't show up, try this:
export GST_PLUGIN_PATH=/usr/local/lib/gstreamer-1.0
/usr/local/lib/gstreamer-1.0 is the default directory used by make in case of plugins. If you have defined a different directory, use it.
Then run gst-inspect-1.0 and you'll find the newly compiled and installed plugin.
You'll be required to perform the export every time in the shell whether you either create a static pipeline with gst-launch-1.0 or run code of your own. I couldn't find any alternative to make it permanent other than making entry of this in .bashrc file. If you have one, please suggest via comments.
If you run ./configure --help in the gst-plugin directory you will see the following:
By default, make install' will install all the files in
/usr/local/bin', /usr/local/lib' etc. You can specify
an installation prefix other than/usr/local' using --prefix',
for instance--prefix=$HOME'.
If you do after the original installation:sudo updatedb && locate libgst[NAME_OF_YOUR_PLUGIN].so you should see where the library holding your plugin is located (in my case it is under /usr/local/lib/gstreamer-1.0/ as described by the configure help above).
Now on my machine, the GStreamer "official" plugins are installed under: /usr/lib/i386-linux-gnu/gstreamer-1.0/ . This is where the new created plugin library should be stored.
To store the plugin at the right place, run configure with the following parameter:
./configure --libdir=/usr/lib/i386-linux-gnu followed by make && sudo make install
It is important to override with --libdir and NOT --prefix! The usage of --prefix will stick a /lib that we don't want to have under /usr/lib/i386-linux-gnu.The plugin will not be found by gst-inspect-1.0 if /lib is added to the path.
Extra note :
Even if the plugin is at the proper location, you may still see GStreamer blacklisting it when you run gst-inspect-1.0. One of the cause of the blacklisting could be the shared library/ies required by your plugin not installed or not found on your platform. The ldd command can help figuring out the dependencies your plugin may have. Just run ldd [YOUR_GSTREAMER_LIBRARY].so