Is there any way to pass some basic values as argument in bower init command? So that there is no need for manually entering the values. for e.g.
bower init --default-params
Related
What I think that I've understood about home-manager.
Instead of using
nix-env iA packageToBeInstalled
you write a list of package in a file (/home/nixos/.config/nixpkgs/home.nix that I from now on call just home.nix)
you run
home-manager switch
and the package are installed.
But I have already installed some packages with nix-env. (home-manager for instance)
I would like to have my configuration save just in home.nix in order to just have to import it and execute home-manager switch to import the exact same configuration in a other OS.
Therefore I need a command replicating my configuration in home.nix.
I am not aware of a tool that fully automates this.
The nix-env list of installed packages is maintained in ~/.nix-profile/manifest.nix, but does not contain the attribute path, which is the "name" you need to use in such configuration files.
To find the attribute paths for the things you've installed, you may first create an index of sorts based on your current nixpkgs (NIX_PATH etc):
nix-env -qaP >packages.tmp
and then use it to look up each package.
Here's a one-liner that doesn't work for all packages.
nix-env -q | while read name; do grep "$name" <packages.tmp; done
So make sure to read through nix-env -q yourself and look up anything that's missing using for example https://search.nixos.org/packages.
To finalize, remove the imperatively installed packages with nix-env -e, check nix-env -q, and rm packages.tmp.
I'm using a shared library with jenkins 2. Meaning, I'm utilizing the ability to reuse some of the pipeline code I'm writing in various stages.
here is an example of module vars/utils.groovy
def set_virtual_env() {
sh """
chmod 777 virt_run_pytest.sh
chmod 777 install_python_venv.sh
pip install -U setuptools
bash install_python_venv.sh
"""
}
When trying to execute it in a pipeline script, it gets failed with the following error:
groovy.lang.MissingPropertyException: No such property: set_virtual_env for class: groovy.lang.Binding
I suspect that the reason for that is because I'm not passing any variable to this function and as a result it's not instantiated correctly.
So the actual question might be, "How can I call a shared library function that does not needs arguments"?
I was calling the object and not the method. meaning, I called it:
utils.set_virtual_env
Instead of
utils.set_virtual_env()
What exactly is the difference between these two operations?
source activate python3_env && python my_script.py
and
~/anaconda3/envs/python3_env/bin/python my_script.py ?
It appears that activating the environment adds some variables to $PATH, but the second method seems to access all the modules installed in python3_env. Is there anything else going on under the hood?
You are correct, activating the environment adds some directories to the PATH environment variable. In particular, this will allow any binaries or scripts installed in the environment to be run first, instead of the ones in the base environment. For instance, if you have installed IPython into your environment, activating the environment allows you to write
ipython
to start IPython in the environment, rather than
/path/to/env/bin/ipython
In addition, environments may have scripts that add or edit other environment variables that are executed when the environment is activated (see the conda docs). These scripts can make arbitrary changes to the shell environment, including even changing the PYTHONPATH to change where packages are loaded from.
Finally, I wrote a very detailed answer of what exactly is happening in the code over there: Conda: what happens when you activate an environment? That may or may not still be up-to-date though. The relevant part of the answer is:
...the build_activate method adds the prefix to the PATH via the _add_prefix_to_path method. Finally, the build_activate method returns a dictionary of commands that need to be run to "activate" the environment.
And another step deeper... The dictionary returned from the build_activate method gets processed into shell commands by the _yield_commands method, which are passed into the _finalize method. The activate method returns the value from running the _finalize method which returns the name of a temp file. The temp file has the commands required to set all of the appropriate environment variables.
Now, stepping back out, in the activate.main function, the return value of the execute method (i.e., the name of the temp file) is printed to stdout. This temp file name gets stored in the Bash variable ask_conda back in the _conda_activate Bash function, and finally, the temp file is executed by the eval Bash function.
So you can see, depending on the environment, running conda activate python3_env && python my_script.py and ~/anaconda3/envs/python3_env/bin/python my_script.py may give very different results.
How does running source activate <env-name> update the $PATH variable? I've been looking in the CONDA-INSTALLATION/bin/activate script and do not understand how conda updates my $PATH variable to include the bin directory for the recently activated environment. No where can I find the code that conda uses to prepend my $PATH variable.
Disclaimer: I am not a conda developer, and I'm not a Bash expert. The following explanation is based on me tracing through the code, and I hope I got it all right. Also, all of the links below are permalinks to the master commit at the time of writing this answer (7cb5f66). Behavior/lines may change in future commits. Beware: Deep rabbit hole ahead!
Note that this explanation is for the command source activate env-name, but in conda>=4.4, the recommended way to activate an environment is conda activate env-name. I think if one uses conda activate env-name, you should pick up the explanation around the part where we get into the cli.main function.
For conda >=4.4,<4.5, looking at CONDA_INST_DIR/bin/activate, we find on the second to last and last lines (GitHub link):
. "$_CONDA_ROOT/etc/profile.d/conda.sh" || return $?
_conda_activate "$#"
The first line sources the script conda.sh in the $_CONDA_ROOT/etc/profile.d directory, and that script defins the _conda_activate bash function, to which we pass the arguments $# which is basically all of the arguments that we passed to the activate script.
Taking the next step down the rabbit hole, we look at $_CONDA_ROOT/etc/profile.d/conda.sh and find (GitHub link):
_conda_activate() {
# Some code removed...
local ask_conda
ask_conda="$(PS1="$PS1" $_CONDA_EXE shell.posix activate "$#")" || return $?
eval "$ask_conda"
_conda_hashr
}
The key is that line ask_conda=..., and particularly $_CONDA_EXE shell.posix activate "$#". Here, we are running the conda executable with the arguments shell.posix, activate, and then the rest of the arguments that got passed to this function (i.e., the environment name that we want to activate).
Another step into the rabbit hole... From here, the conda executable calls the cli.main function and since the first argument starts with shell., it imports the main function from conda.activate. This function creates an instance of the Activator class (defined in the same file) and runs the execute method.
The execute method processes the arguments and stores the passed environment name into an instance variable, then decides that the activate command has been passed, so it runs the activate method.
Another step into the rabbit hole... The activate method calls the build_activate method, which calls another function to process the environment name to find the environment prefix (i.e., which folder the environment is in). Finally, the build_activate method adds the prefix to the PATH via the _add_prefix_to_path method. Finally, the build_activate method returns a dictionary of commands that need to be run to "activate" the environment.
And another step deeper... The dictionary returned from the build_activate method gets processed into shell commands by the _yield_commands method, which are passed into the _finalize method. The activate method returns the value from running the _finalize method which returns the name of a temp file. The temp file has the commands required to set all of the appropriate environment variables.
Now, stepping back out, in the activate.main function, the return value of the execute method (i.e., the name of the temp file) is printed to stdout. This temp file name gets stored in the Bash variable ask_conda back in the _conda_activate Bash function, and finally, the temp file is executed by the eval Bash function.
Phew! I hope I got everything right. As I said, I'm not a conda developer, and far from a Bash expert, so please excuse any explanation shortcuts I took that aren't 100% correct. Just leave a comment, I'll be happy to fix it!
I should also note that the recommended method to activate environments in conda >=4.4 is conda activate env-name, which is one of the reasons this is so convoluted - the activation is mostly handled in Python now, whereas (I think) previously it was more-or-less handled directly in Bash/CMD.
Adding a runtime dependency to a package through override buildInputs causes the package to rebuild. Is there a simple way to inject runtime dependencies into a package without recompiling?
So basically adding package/bin to PATH and package/lib to LD_LIBRARY_PATH
If I understand correctly that you want to tweak the environment used when a Nix-installed app is run, not the one used when it is built, then a method I know of is as follows below. By using it, you essentially create a wrapper script, which overrides the "default command". So, something similar like creating e.g. a custom ~/bin/vim script, which adds some options/env overrides to the default vim binary, which is called with a "hardcoded original path" inside the script.
One example of it in nixpkgs is how vimutils.vimWithRC overrides vim command with a custom script. For your own use, you could write more or less something like below:
with import <nixpkgs> {};
writeScriptBin "vim" ''
#!/usr/bin/env bash
export PATH=package/bin:$PATH # whatever you like; I've added what you asked for
export LD_LIBRARY_PATH=package/lib:$LD_LIBRARY_PATH
${vim}/bin/vim --my-options "$#"
'';
If you put it in my-vim.nix, you should be able to install it with:
$ nix-env -e vim # REMOVE NORMAL VIM. I think this should be done first to avoid conflict
$ nix-env -i -f my-vim.nix
And hopefully it'll work and "override" the default vim for you.
DISCLAIMER: I haven't actually tested it in this exact form, sorry. Don't have a Nix console handy at this moment, unfortunately.