Was looking through the gRPC docs and they mention that:
We strongly encourage you to install gRPC locally — using an
appropriately set CMAKE_INSTALL_PREFIX — because there is no easy way
to uninstall gRPC after you’ve installed it globally.
There, they mention to try something like export MY_INSTALL_DIR=$HOME/.local. I'm wondering: what kind of packages should go under /usr/local, and what packages shouldn't? gRPC seems to be a well-maintained repo, so I'm not sure 1) why, other than the difficulty of uninstalliation, /usr/local isn't okay, and 2) why it is so difficult to remove it after installing globally.
Related
I am trying to setup watchman for the mac. As stated on the website, I need to install glibtool.
Can anyone provide a link to where I can download glibtool?
I need to be able to download it from its source and the only solution I can find is by using brew.
I do not want to use brew.
Thank you.
glibtool is "GNU Libtool". It is typically installed as libtool on most systems, but because macOS has its own libtool that has completely different functionality, it is usually installed as glibtool on macOS.
If you can't directly use homebrew to install it, you can duplicate the steps in its recipe, which you can find here: https://github.com/Homebrew/homebrew-core/blob/master/Formula/libtool.rb
For the sake of keeping this answer "working" even if homebrew goes away, the homepage for libtool is https://www.gnu.org/software/libtool/ and you can follow the instructions there for information on how to build and install it.
I've covered similar issues to Wez's answer from a MacPorts perspective; I'll go ahead and assume you can't use that either.
The latest stable version at this time is 2.4.6. Typical best practice is to make a directory, e.g., build in the top level of the source. Add the prefix: g, with --program-prefix=g, the top level installation directory --prefix=PREFIX, or specify more fine-grained installation directories options for bin, include, lib, and share directories.
> mkdir build
> cd build
> ../configure --prefix=/my/install/path --program-prefix=g
> make; make install
You now have glibtool and glibtoolize in $PREFIX/bin.
I come from a Python and JavaScript background.
When developing a JavaScript project, dependencies are installed in a node_modules directory in the project root.
When developing Python project, typically virtualenvwrapper is used. In this case dependencies are installed in a virtual environment, which is located in ~/.virtualenvs/<project_name> by default.
Now I need to use a ruby tool for a project. The tool that appears to be the most promising for a similar setup as described above, is bundler.
However, the default installation location for bundler is system-wide. I consider this to be harmful.
For one of my systems, it will prompt for a password, at which point I can still abort.
However, for my other system I can write into the global ruby installation. I'm using a homebrew installed ruby here. Bundle will just install dependencies globally.
I know I can specify the installation location by adding --path, but this is easy to forget.
One way to enforce an installation path is by committing .bundle/config. It would just have to contain this:
---
BUNDLE_PATH: "."
However, some googling around shows that it's not adviced to commit this file.
What is the recommended way to prevent accidental global installations using bundler?
Who's to say it will be accidental? It really depends on what context you're talking about here. I have my Ruby set up so that bundle install works without requiring sudo, it's all done through rbenv automatically. The same is true with rvm if done as a user-level install.
When it comes to deploying apps and you want to make sure it's deployed correctly, that's where tools like Capistrano come into play: Create a deployment script that will apply the correct procedure every time.
Checking in a .bundle/config is really rude from a dev perspective, just like checking in any other user-specific preferences you might have. It causes no end of conflict with other team members.
I am using Coq (versions 8.5-6), installed w/ Nix. I want to install ssreflect, preferably also w/ Nix. The only information I found about this is here. However, this is not about installing ssreflect, merely trying it out. Nevertheless, I tried to try it out, but ended up w/ hundreds of warnings (about the contents of various .v and .ml4 files) and couldn't wait for the process to end. A fairly typical warning looked like this:
File "./algebra/ssralg.v", line 856, characters 0-39: Warning:
Implicit Arguments is deprecated; use Arguments instead
So the question: How on earth do I install ssreflect w/ Nix?
EDIT: After reading ejgallego's comments, it seems it may be impossible to install ssreflect w/ Nix -- esp. if one wants install only ssreflect w/out the other modules (fingroup, algebra, etc.). So I've also the following question:
Would the standard Opam or make install installation of ssreflect work w/ a Nix-installed Coq?
There are a few things that you need to be aware of:
Nix is a source-based package manager with a binary cache. A lot of packages are pre-built and available in the binary cache, thus their installation doesn't take long; some packages (in particular development libraries) are not pre-built and Nix, when installing them will take the time it needs to compile them. Please be patient: you will only need to wait for the full compilation the first time (and yes, math-comp emits lots of warning upon compilation); next times, the package will be already available in your local Nix store.
Since OPAM is also source-based, using OPAM instead of Nix won't make you save time. You can't mixup Nix-installed Coq with OPAM installed SSReflect because the latter will want the former as an OPAM dependency.
The Nix way to use libraries is not to install them but to load them with nix-shell instead. nix-shell will "install" the libraries and set some environment variables for you (e.g. $COQPATH in this case).
You can also compile the package from source yourself using a Nix-installed Coq but you cannot run make install because this would try to install SSReflect at the same place where Coq is installed but the Nix store is non-mutable. Instead you could skip this step, and set up $COQPATH manually.
Indeed, the compilation of the full math-comp takes very long. There is a Coq ssreflect package which is lighter. You can get it using:
nix-shell -p coqPackages_8_6.ssreflect
I'm trying to install a go project (the keybase client, in particular), but I want to install it globally for all the users on my system.
I've searched around and found a few people who accidentally install things to /usr/local/go/bin or something to that effect, but no instructions on how I actually should be installing things to such locations.
But that's what I want to do - globally install the application. How should I be doing that with go?
I'm not using any of the pre-built packages because none exist for Raspbian Jesse.
Have you tried setting $GOBIN like:
GOBIN=/usr/local/bin/ or GOBIN=/usr/bin/ or any directory in the PATH?
and then:
export GOBIN
and then install the app?
According to the manual the default $GOBIN is $GOROOT/bin so I guess those users set GOROOT to /usr/local/go
The approach that I've taken is this:
PATH="$PATH:/usr/local/go/bin" GOPATH=/usr/local/go/ go get github.com/keybase/client/go/keybase
PATH="$PATH:/usr/local/go/bin" GOPATH=/usr/local/go/ go install -tags production github.com/keybase/client/go/keybase
Which ends out installing keybase to /usr/local/go/bin/keybase. It's possible that there's a better way, but so far I haven't seen one.
Maybe it's because I'm new to shared environments where I have no root access or the dpkg/apt family of tools, but I wanted to install from source (for instance, gcc/gdb), possibly by using wget to grab the tarball, unpack it, and point configure --prefix=$HOME, before calling make; make install, but I'm having some issues. Namely, the whitelist (obvious), and secondly the configure step is giving me trouble.
Can someone walk me through this process? Pythonanywhere comes with make, so it's not as if they don't want you doing this.
EDIT
Perhaps gcc/gdb may not be the best example -- together they are close to half the 500MB allotment for free accounts.
Any pure python modules will install with ease. Unfortunately you can't install modules that require a compiler. The Python Anywhere staff is generally very accommodating to get packages requested installed to the battery's included for all to enjoy.
Feel free to make a request to the PA forum
or
Email the staff: support#pythonanywhere.com
For clarity. To install a pure python module you just use
pip-3.2 install --user <package_name>
Change 3.2 as needed for the Python version you want and of course change <package_name> to your desired package.