I installed virtualenv + virtualenvwrapper via virtualenv-burrito. However, it seems to be giving me problems now in uninstalling packages from my virtualenvs (case in point, distribute).
It seems that the distribute used by my virtualenvs is the one at /home/skrd/.venvburrito. If, inside a virtualenv, I try to upgrade distribute, it installs to /home/skrd/.virtualenvs but the virtualenv itself is still using the one at /home/skrd/.venvburrito. With that, the packages needing an updated distribute still won't work.
See,
(test)$ $ pip uninstall distribute
Not uninstalling distribute at /home/skrd/.venvburrito/lib/python/distribute-0.6.27-py2.7.egg, outside environment /home/skrd/.virtualenvs/test
I've tried renaming the .venvburrito directory (equivalent to deleting it, but with back-up) but that breaks my virtualenvs. How do I uninstall packages now?
I still don't understand what happened here but I just had the idea to check what's installed for my system's Python outside virtualenv. There I saw distribute, with a similar version to the one that's giving me problems inside a virtualenv.
I upgraded the non-virtualenv installation of distribute and, next time I checked in my virtualenv, the distribute installation has also upgraded.
(So, yes, I'm aware that my question's original intent is to remove distribute. But that was just an intermediary step to updating it---the update was unable to proceed since it can't remove the distribute currently installed. So, there, problem solved.)
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.
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 installed the program dolphin-emu on Ubuntu 16.04, but wanted to remove it and install a different version. I tried removing it but I can't see the package when searching for "dolphin" using "sudo apt-get --purge remove ..." or "apt list -installed" (the package should be called dolphin-emu). However I can still run the application from the user interface in Unity so it is clearly still installed.
I tried installing the version I want but it does not come up when I try to run it, only the older version that I want to get rid of! I tried to manually remove files and such but I think that made the whole thing worse and now I'm in some kind of mess that I can't resolve...
I'm a RHEL newbie. I'm used to a non-Linux Unix, which has a fundamentally different way of dealing with packages.
I want to install ipython for a user on a vanilla RHEL7 system with yum as the package manager.
"yum install python" was fairly straightforward, but given that I'm new to the OS and I don't completely understand what ipython is, I am stumped as to how to proceed.
"yum install ipython" obviously doesn't work and every possible solution seems to require the installation of something else that I don't know how to install in a reasonable manner.
I am trying to keep things as generic as possible so it will be obvious how to update/remove software in the future, so anything that can be done with yum, would be probably preferable.
Installation instructions refer to pip, which I don't have. I possibly need setuptools to run pip, but I can't figure out the appropriate way to get that either. Maybe I can get one or either by installation the EPEL bundle of packages, but I can't find those for RHEL7, at least not in a way that doesn't seem like a "download and install this random file, trust us" method, which seems irresponsible.
Another option is anaconda. Again, there doesn't seem to be a yum-related way to install this, and anaconda itself is only a means to an end to download ipython, so that'd be two levels of abstraction away from the goal.
Additionally, do I even want "ipython" these days, or do I want "jupyter"?
All I care about is that the user should be able to type in "ipython" at the prompt and get the thing he is expecting.
Also, the python installed by yum is 2.7.5-48.el7, which does not seem to be current. I don't care about using the current version unless that prevents me from successfully installing ipython in some other manner, but I thought it might be relevant.
Any suggestions for how to install this thing is the most easily maintainable way? Do I not want the yum version of python?
Thanks for your patience.
Install python-pip from EPEL repository first ( https://fedoraproject.org/wiki/EPEL - it's compatible with all Red Hat entrprise Linux distros - be it CentOS, RHEL, Oracl, ScientificLinux or whatever), (or if you don't trust EPEL repo providers you can use get-pip.py ( https://bootstrap.pypa.io/get-pip.py ) script, but then you have to trust its providers instead) then install via
pip install ipython
system : MAC OS 10.11.6
The error message :
Error: could not connect to website
(url->port: bad reply from server: #<eof>)
I don't know if I can simply drag the "Racket v6.2.1" folder in Application to Trash and then install the newest version of DrRacket.
This was, unfortunately, a bug in Racket that was present in v6.2.1. It has since been fixed (by me, in this commit), but given that you have a version with the bug, you’ll have to update it manually.
Each installation of Racket basically exists within its own sandbox, though, so you should be able to install the new version alongside v6.2.1 without any problems, and you can check if it works. Things like settings will be preserved across versions, but installed packages will not be.
I think DrRacket may prompt you to migrate your packages when you launch a new version, but I honestly forget. However, you can manually migrate your old packages from another version using the raco pkg migrate command. Otherwise, it’s not much of a loss—you can always just reinstall them.
Once you’ve migrated your packages (or decided you don’t want or need to), you can safely delete your old installation’s directory.