I installed Mercurial, only to realize that it's not supported yet with MonoDevelop, and then realized that I have no clue how to properly uninstall it.
I've googled around and can't find anything to support uninstalling it.
MonoDevelop's support for version control is lagging, and only basic support for Git will be added in version 2.6. I would suggest keeping Hg installed and use the command line. You shouldn't dismiss using a great DVCS just because your IDE doesn't integrate with it.
Since Hg is Python based, you may be able to use easy_install to uninstall it for you.
easy_install -m mercurial
See easy_install documentation for more information
You can uninstall mercurial by deleting the executable, but this seems to be the only way to fix the problem. The executable is in /usr/local/bin or in usr/local/bin/hg (I'm not quite sure), but deleting the executable (and all related files) is a dirty, but working, way to uninstall mercurial.
I did:
sudo rm /usr/local/bin/hg # To remove my local version (yours may be elsewhere)
sudo pip uninstall mercurial # To remove mercurial from my Python
Pip is not install by default so I guess you can use:
easy_install -m mercurial # Like Steve suggests
This recipe works well for me.
I had luck following the suggestion of this post on the mercurial listserv:
Launch again the mpkg you used for the installation, go to the second
window (Read me or something similar) and check the "After the
install" section.
On Mac OS X 10.6, the text is: This package installs the hg executable
in /usr/local/bin and the Mercurial files in
/Library/Python/2.6/site-packages/mercurial.
I can imagine you have to replace 2.6 by 2.7 on Mac OS X 10.7.
Though totally forgotten how I installed it, the following did the work for me.
sudo rm -fr /usr/local/lib/python2.7/site-packages/mercurial*
Open Terminal and type this command.
defaults write com.apple.finder AppleShowAllFiles -boolean false;killall Finder
Why not simply use the prompt or a 3rd party gui for mercurial? This is usually preferred over IDE Integration for speed/reliability anyways.
Related
I'd like to install programs with conda in one particular conda environment and to be able to use the associated commands from all conda environments.
My goal is to allow students to install Mercurial (plus few Mercurial extensions and related utilities like Meld and TortoiseHg) on any platforms (especially Windows) with one simple command (or few simple commands), and of course without compilation.
Of course the hg command should be available in the terminal from any conda environments (anaconda prompt on Windows). The Mercurial packages cannot be installed in the base environment because Mercurial still works better in Python 2.7 (anyway, it wouldn't be clean).
Now Mercurial and the extensions we need can be installed on all platforms with something like:
conda create -n py27_mercurial -c conda-forge python=2.7 mercurial dulwich ipaddress
conda activate py27_mercurial
pip install hg-evolve hg-git
Working a bit with conda-forge and a conda meta-package, it won't be difficult to do that with one very simple command. Moreover, it should not be difficult to create conda packages for Meld and TortoiseHg.
From this stage, the hg command is available when the environment is activated (and it is very simple to install other Mercurial extensions). To make it available from other environment (and in the base environment), one need to append the path of the directory containing hg to the environment variable PATH or on Unix to create a symbolic link (I don't know Windows enough to know if something similar would work). Both solutions are not straightforward and the commands are not platform independent.
I didn't find a command to do something like this in conda but sometimes conda experts are able to do impressive things! What would be an elegant solution to this issue?
It would also be nice to create icons somewhere (in the Anaconda launcher?) for the graphical applications (Meld and TortoiseHg). Is it possible?
Edit: Conda applications
I discovered that there is a way to specify in the meta.yaml file that a package is an application: https://docs.conda.io/projects/conda-build/en/latest/resources/define-metadata.html#app-section
It may help to solve the issue.
Edit after a first answer based on a bash function:
Of course, I'm looking for a solution involving very small work (and understanding) for the users and with cross-platform commands.
Note that for Linux and Bash, one can just do:
CONDA_APP_DIR=$HOME/.local/bin/bin-conda-app/
mkdir -p $CONDA_APP_DIR
echo -e "\nexport PATH=\$PATH:$CONDA_APP_DIR\n" >> ~/.bashrc
ln -s $(which hg) $CONDA_APP_DIR/hg
No need to activate/deactivate the environment each time hg is used...
Of course, such solutions dependent of the system and the shell are not satisfactory. It should be possible to do such things with cross-platform conda-like commands (see https://github.com/conda/conda/issues/8556), something like
conda config --add channels conda-forge
conda install conda-app
conda-app install mercurial
Now, I just have to implement conda-app 🙂
One can always create a shell function/alias and shove it in their shell's runtime configuration file. For example, for your use case, I'd add the following in my ~/.bashrc:
hg() {
(conda activate py27_mercurial
command hg "$#"
_hg_exit_code=$?
conda deactivate
exit $_hg_exit_code)
}
Then, regardless of which environment you are in, you always run hg from the environment it was installed in. To make sure that this function is loaded for you shell in a new session, one can always take a look at the output for: type -a hg
I do this one-time-setup for all the tools (some are custom compiled) and have an alias/shell function for each. This way I can happily switch b/w environments without having to worry much.
The solution https://stackoverflow.com/a/55900964/1779806 is buggy for scripts using command hg ... and too inefficient for this case (installation of a command-line application). See https://github.com/conda/conda/issues/8556#issuecomment-488703716
I created a tiny Python package conda-app (https://pypi.org/project/conda-app/) to improve this situation.
This should now works on Unix systems (with Bash and Fish):
conda activate base
conda config --add channels conda-forge
pip install conda-app
conda-app install mercurial
It should not be difficult to improve conda-app to also support Windows.
For the time being, Windows users can install Mercurial and important extensions by installing TortoiseHG.
I've tried dozens of guides on installing mercurial and keyring extensions on Ubuntu and have never been able to get the keyring extension to work. It was a snap under Windows.
I've installed mercurial many different ways. I'm not sure if the install method has anything to do with the keyring, but here are a few of the things I've tried:
sudo apt-get install mercurial
sudo apt install mercurial
pip install mercurial
... and so on.
I even used this method where it compiles mercurial.
All of these methods work for mercurial. It runs. I can do commits, etc. It's keyring and mercurial_keyring installations that are giving me trouble. I installed both of those using pip install. When I do a command like:
hg out http://somerepo
At the moment, I'm getting the following message:
No handlers could be found for logger "keyring.backend"
I feel like there is a concise set of steps to get keyring working, but it's just eluding me. I've made half a dozen attempts on fresh virtual machines and can never get this to work. :(
pip uninstall keyring
The reason is that python has already the library python-keyring installed which conflicts with the one installed with pip. Credits to Python library woes on Ubuntu 18.04 by Kai Koenig
Edit: the story actually did not end there because what it did was to get rid of that error but was not the actual solution. I had to continue with these commands
pip install keyrings.alt
pip install keyring
(yes, I installed it back)
python -c "import keyring.util.platform_; print(keyring.util.platform_.config_root())"
That was taken from keyring docummentation. It turned out that my config folder shown by this command was not created so I did:
mkdir ~/.local/share/python_keyring
vi ~/.local/share/python_keyring/keyringrc.cfg
I had to create the .cfg file as well and put this inside (on my MacOS Mojave!):
[backend]
default-keyring=keyring.backends.OS_X.Keyring
Now everything works fine, no password asked anymore
I am trying to setup a MySQL server using CentOS (No GUI) and I need to switch to OpenSSL instead of YaSSL in order to have access to the encryption tools.
The issues happen when runing the cmake. At first I got the error that cmake was not able to find boost, I fixed this adding the parameter -DWITH_BOOST.
The cmake line is as follows.
cmake . -DWITH_READLINE=ON -DWITH_SSL=system -DWITH_BOOST=/usr/local/src/mysql-5.7.20/boost/
After the adjustment I ran again the CMAKE the I got several errors.
SSL Error, cmake can not find the OpenSSL files. I checked if the library was installed, I also downloaded the tar.gz file and decompress it and pointed the cmake to the folder, none of this worked.
Can not find NUMA libraries, again I checked and it is installed, at this point I ran the system update to check for everything but this did not solve the issue.
Can not find the ncurses, the same thing, is on the system but for some reason cmake is not able to find those.
Can not fin libaio, I didn't have this one installed, I installed, ran cmake again, and again cmake was not able to find it.
I been looking around, trying to figure out all this issues, I've been joining information from different websites but still not able to figure out this.
Thanks ahead to everyone for the help.
You're facing the dependencies hell with MySQL. If you don't really need to compile from the sources, you still can install with the RPM which is much easier. The RPM method is described here : https://dev.mysql.com/doc/mysql-yum-repo-quick-guide/en/
As you're asking a ready-to-go install from the sources, this is what I just did and it worked, on a fresh CentOS 7.4 minimal, 2 vcpus 3Gb :
yum group install -y 'Development Tools'
yum install -y cmake ncurses-devel curl
curl -Ovk https://cdn.mysql.com/Downloads/MySQL-5.7/mysql-5.7.20.tar.gz
tar zxf mysql-5.7.20.tar.gz
cd mysql-5.7.20
cmake . -DDOWNLOAD_BOOST=1 -DWITH_BOOST=$HOME/boost -DENABLE_DOWNLOADS=1
make -j2
make install
After that you need to configure it, add the startup scripts, and of course secure it. Here are some additional docs :
http://howtolamp.com/lamp/mysql/5.6/installing/
https://dev.mysql.com/doc/refman/5.7/en/mysql-secure-installation.html
Perhaps try make clean; cmake clean; ldconfig then run your cmake command. Sometimes the system can't find the shared libraries, and ldconfig refreshes the library search path. This helped once when I was compiling something (emscripten?) which required a lot of libraries which I was installing as compilation errors arose.
The make clean; cmake clean will ensure that the compiler isn't looking at the old library search path when you recompile.
I am quite new to this. Is there a certain repo I'm supposed to install? If so could you tell me it and what command I need to put in. Thanks.
libssl0.9.7 on Debian.
I don't think there are any repos that still have that version. Installing such an old version of OpenSSL is NOT recommended as it comes with way too many vulnerabilities to list. But if you still want that version, you can download it here: http://archive.debian.net/etch/amd64/libssl0.9.7-dbg/download
Here are the commands to install it:
wget -c http://archive.kernel.org/debian-archive/debian/pool/main/o/openssl097/libssl0.9.7-dbg_0.9.7k-3.1etch5_amd64.deb
sudo dpkg -i libssl0.9.7*.deb
sudo apt-get -f install
Since it's an old version, there's no guarantee that it'll be compatible with new systems. You may receive some errors after completing the installation.
Using ruby 2.0.0. mvim is built with ruby support enabled. Use the .vba approach to install the plugin. Now whenever I launch mvim it SEGVs. If I remove the CommandT plugin all is back to normal.
THe architecture flag is -arch x86_64 so I didn't override the arch flag to 32 bit when running make in the ./ruby/command-t directory.
Also tried to uninstall and install mvim but no luck.
Any ideas?
After some more googling found the link: http://arjanvandergaag.nl/blog/compiling-vim-with-ruby-support.html. So yes, vim and CommandT were compiled with different versions of ruby support.
Did the following:
brew edit macvim
Updated --with-ruby-command to point to rvm ruby path which CommandT was using.
brew uninstall macvim
brew install macvim
The original Formula had --with-ruby-command set to ${RUBY_PATH}. So my solution is a little hacky. What's the right way to get brew to follow rvm default ruby path?