I am new to NixOs and nix-shell and am still getting to know its idioms. Right now I have a Java project which I am using nix-shell via direnv to load up the build tool chain, including a jdk and bazel.
I would like the IDE - in my case ItelliJ - to use this same toolchain. My naive approach is to use a nix-shell script as follows, which is the default.nix in the root of my project, and the one picked up by direnv.
with import <nixpkgs> {};
stdenv.mkDerivation {
name = "my-project";
buildInputs = with pkgs; [
jdk11
bazel
jetbrains.idea-ultimate
];
shellHook = ''
export JAVA_HOME="${pkgs.jdk11}/lib/openjdk"
ln -s ${pkgs.jdk11}/lib/openjdk ./jdk
'';
}
I can then launch IntelliJ with the following command from the shell:
$ idea-ultimate 2>1 > /dev/null &
While it works, I have the following concerns:
Loading up the IDE into my command line shell seems really heavy, especially for the CI build.
It is going to get worse as I add other IDEs the team uses, like Eclipse.
It seems like the wrong way.
I can, of course, install these IDE packages using other Nix facilities, like home manager, which gives me the application launcher in the menu after the right config steps; however, I like directly launching the IDE from the shell to ensure the correct tool chain is in place and in correct paths.
My thought for a next step was to remove the IDE input from this default.nix and create custom nix files which include the inputs for the IDE and a launcher script to actually launch the IDE with nix-shell. My hope is that, if executed from the shell above, it will inherit its inputs, augment it with the IDE input, and then launch the IDE.
Again, my goal is to use nix to launch my IDEs, and use the packages and configs setup by the default.nix which is in the root of the project to ensure consistency.
Suggestions, including alternative approaches, are appreciated.
Related
I have a kinda weird problem. I'm currently messing around with the VRX-Simulator, which simulates an unmanned-watersurface-vehicle.
For the installation I followed the guide on https://bitbucket.org/osrf/vrx/wiki/tutorials/SystemSetupInstall.
Then I tried to modify some of the files and tried to rebuild the project.
This was the point when I noticed it always used the "old" version of my simulation within gazebo.
From now on no matter what I did (I even deleted the whole catkin workspace folder) ROS somehow managed to always launch the original version of my simulation even without any build/src folder existing when I used roslaunch.
roslaunch vrx_gazebo sandisland.launch
So my question would be how can I get rid of my simulation/model and where does ros/gazebo cache my simulation?
You most probably installed the package with the command from the tutorial sudo apt install ros-melodic-vrx-gazebo. So the package launched with roslaunch vrx_gazebo sandisland.launch was not in your catkin workspace. If you want to get rid of it you can uninstall it with sudo apt remove ros-melodic-vrx-gazebo. But this is not strictly necessary.
There are several ways to find out where some ros package is located, try running some of these commands:
rospack find vrx_gazebo will show you where the package used is located
roscd vrx_gazebo will take you to the folder where it is installed something like
/opt/ros/melodic/share/vrx_gazebo
If you also followed the tutorials installing from source code then the issue most likely was not sourcing the built packages. The last line of the guide is a bit misleading. The line *Remember to run this command every time you open a new terminal. is meant to reference the command source ~/vrx_ws/devel/setup.bash
Whether the installed package or the package built from source is used depends on which order they are listed in the environment variable ROS_PACKAGE_PATH. This variable is modified by both source /opt/ros/melodic/setup.bash and source ~/vrx_ws/devel/setup.bash. So have a look at the variable after each step with printenv | grep ROS or echo $ROS_PACKAGE_PATH. Theoretically if you source your terminal in the order I had the source commands it should be using the package built from source, you can verify with the rospack find ... and roscd ... commands mentioned earlier.
In the end it is probably easier to add the sourcing commands to your .bashrc file so you would not forget to source the terminals as mentioned in the ROS installation tutorial. You can add the sourcing of the workspace to the the same file, you will just have to be aware that you would need to change the file, should you want to use a different workspace.
http://wiki.ros.org/melodic/Installation/Ubuntu#melodic.2BAC8-Installation.2BAC8-DebEnvironment.Environment_setup
relevant command from the tutorial:
echo "source /opt/ros/melodic/setup.bash" >> ~/.bashrc
you could do the same for the workspace:
echo "source ~/vrx_ws/devel/setup.bash" >> ~/.bashrc
And after running those commands run exec bash to get the changes into the current terminal. All future terminals will have those commands already loaded.
I have cloned and built the waf script using:
./waf-light configure
Then to build my project (provided by Gomspace) I need to add waf and the eclipse.py to my path. So far I haven't found better than this setenv script:
WAFROOT=~/git/waf/
export PYTHONPATH=$WAFROOT/waflib/extras/:$PYTHONPATH
export PATH=~/git/waf/:$PATH
Called with:
source setenv
This is somehow a pretty ugly solution. Is there a more elegant way to install waf?
You don't install waf. The command you found correctly builds waf: /waf-light configure build Then for each project you create, you put the built waf script into that projects root directory. I can't find a reference, but this is the way in which waf:s primary author Thomas Nagy wants the tool to be used. Projects that repackage waf to make the tool installable aren't "officially sanctioned."
There are advantages and disadvantages with non-installation:
Disadvantages:
You have to add the semi-binary 100kb large waf file to your repository.
Because the file contains binary code, people can have legal objections to distributing it.
Advantages:
It doesn't matter if new versions of waf break the old API.
Users don't need to install waf before compiling the project -- having Python on the system is enough.
Fedora (at least Fedora 22) has a yum package for waf, so you could see that it's possible to do a system install of waf, albeit with a hack.
After you run something like python3 ./waf-light configure build, you'll get a file called waf that's actually a Python script with some binary data at the end. If you put it into /usr/bin and run it as non-root, you'll get an error because it fails to create a directory in /usr/bin. If you run it as root, you'll get the new directory and /usr/bin/waf runs normally.
Here's the trick that I learned from examining the find_lib() function in the waf Python script.
Copy the waf to /usr/bin/waf
As root, run /usr/bin/waf. Notice that it creates a directory. You'll see something like /usr/bin/.waf-2.0.19-b2f63c807a4215294bf6005410c74c18
mv that directory to /usr/lib, dropping the . in the directory name, e.g. mv /usr/bin/.waf-2.0.19-b2f63c807a4215294bf6005410c74c18 /usr/lib/waf-2.0.19-b2f63c807a4215294bf6005410c74c18
If you want to use waf with Python3, repeat Steps 2-3 running the Python script /usr/bin/waf under Python3. Under Python3, the directory names will start with .waf3-/waf3- instead instead of .waf-/waf-.
(Optional) Remove the binary data at the end of /usr/bin/waf.
Now, non-root should be able to just use /usr/bin/waf.
That said, here's something to consider, like what another answer said: I believe waf's author intended waf to be embedded in projects so that each project can use its own version of waf without fear that a project will fail to build when there are newer versions of waf. Thus, the one-global-version use case seems to be not officially supported.
So I've installed Nix on Arch linux and I'm able to run nix-env -i example, however how can I define a Nix configuration?
As I don't have any /nixos/configuration.nix file present.
Is this possible?
My goal here is to be able to define a configuration which I could then use something like nixos-rebuild switch to install and provision all the software.
I use NixOS, but I use /etc/nixos/configuration.nix to describe my system; I keep it fairly minimal and prefer not to install "user" software by editing configuration.nix.
So what I do instead is use my ~/.nixpkgs/config.nix (which I believe you also have an equivalent of even in a non-NixOS nix install? I've never actually used nix separately).
The basic structure I use is this:
{
packageOverrides = nixpkgs: with nixpkgs; rec {
mine = with pkgs; buildEnv {
name = "mine";
paths = [
# your packages here
];
};
};
}
buildEnv is a convenience function from nix that makes an "environment" package out of a bunch of others; installing the package mine depends on (and so installs) all of the things listed in paths, and also makes sure they get included in PATH and things like that.
Then I just use nix-env -riA nixos.mine to deploy changes I've made to my environment description (or to rebuild my environment following channel updates). The -r tells it to remove everything else other than mine from the new generation of my profile, which means I can (ab?)use nix-env -i some-package as a way of "temporarily" installing some-package, and if I don't decide I like it enough to actually record it in my config.nix it'll just get removed anyway next time I deploy.
You can certainly create your own configuration. For example, you can do something like this:
let
pkgs = import <nixpkgs> {};
in
{
packages = [
pkgs.vim
pkgs.gimp
];
}
That would produce a set containing an attribute called packages, containing a list of Nix packages. But, you'd need to develop a tool to build environments from this, which is part of what nix-env does. For example, the tool can use nix-env to determine what is already installed, compare that to the selected packages in the configuration, and then install/uninstall packages accordingly.
You don't have a /etc/nixos/configuration.nix because that's NixOS-specific. So while you can do as you asked, you'd have to roll your own solution.
How do you execute a lua file in sublime text 3? I tried opening the console and typing build <filename>.lua. I also looked through the menu's for a build and run. Supposedly saving a file or hitting F7 is supposed to execute lua scripts, but that did not work either. I expected 'helo world' to print in the console upon save and all it said was the file was written.
contents of helo.lua:
print('helo world');
You can manually create a build configuration for Lua. However, I suggest that it is simpler to install a Lua package that includes one.
Install Package Control
Open the Command Palette (Ctrl-Shift-P on Windows or COMMAND + SHIFT + P on Mac)
Type something like "packins" to get the "Package Control: Install Package" item.
After a momentary pause a list of available packages will appear. Type "Lua" to filter to Lua packages.
My personal favorite is "Lua Dev". Select this package and Package Control will download and install the package for you.
From now on, if your have your syntax set to Lua for a file (Ctrl-Shift-P, "Set Syntax: Lua", or click in the bottom right corner of the window and choose Lua) then pressing F7 (aka Tools->Build) will evaluate the file using the Lua interpreter.
You may also need to install "Fix Mac Path". At the time of this writing this package was not found by Package Control. Alternatively, install "Fix Mac Path" by running the following command in terminal:
git clone https://github.com/int3h/SublimeFixMacPath.git ~/Library/Application\ Support/Sublime\ Text\ 3/Packages/FixMacPath
Go to Tools > Build System > New Build System.
Paste this code
{
"cmd": ["lua", "$file"],
"file_regex": "^lua: (...*?):([0-9]*):?([0-9]*)",
"selector": "source.lua"
}
Save it as lua.sublime-build
To run a lua program press ctrl+B.
PS: Ensure that lua executable is in you $PATH
As I can run multiple versions of groovy / grails without having to change settings?
GVM (Groovy enVironment Manager) is a great option if you're on Mac, Linux, Solaris, or Windows with Cygwin. GVM supports the installation and management of Groovy, Grails, Griffon, and Gradle.
If Grails is your primary concern and you use a Windows PC in a locked down enterprise where Cygwin isn't an option, look at Gravy or write a batch file as noted above.
It's only about GROOVY_HOME/GRAILS_HOME and PATH environment variables. Start your Grails application from a bat file/shell script which sets these two variables, and you're fine.
Grails distinguishes settings stored in home/.grails for different versions, so versions won't clash there.
If you're on linux or osx, theres a shell script here which might help, and an alternative script is here
I am using 7 grails version on my ubuntu machine . put the code below at the bottom of .bashrc file.
function switchGrails() {
echo “Switching to grails version: $1″
sudo rm /opt/grails
sudo ln -s /opt/$1 /opt/grails
echo “Done!”
}
alias grails225=’switchGrails “grails-2.2.5″‘
alias grails224=’switchGrails “grails-2.2.4″‘
alias grails223=’switchGrails “grails-2.2.3″‘
alias grails233=’switchGrails “grails-2.3.3″‘
alias grails235=’switchGrails “grails-2.3.5″‘
alias grails237=’switchGrails “grails-2.3.7″‘
alias grails2311=’switchGrails “grails-2.3.11″‘
After save and exit . Compile the .bashrc file . Type cd and . .bashrc to compile .bashrc file.
For more reference : https://pkashyap28.wordpress.com/2014/09/11/manage-multiple-grails-application-in-ubuntu/
Add a tip if you are working on Windows: there's a way for quick-changing version of GRAILS. You just need to change GRAILS_HOME & GROOVY_HOME (by script, GUI,...) then CLOSE the cmd window used to run grais-app, then start it again. By this way, the change will be applied and you can avoid restarting.
Following the #tim_yates' answer. (unix based OS).
1- Put all grails versions under opt folder:
/opt/grails-2.3.1
/opt/grails-2.5.3
/opt/grails-3.1.1
2- Download and save grails.sh in somewhere you know. (I put mine at /opt/grails-selector)
Edit your ~/.bash_profile file. The PATH var should point to the folder you put your grails.sh. And set GRAILS_HOME to your default version (in case you are creating a new project, for example, it'll use this default version unless you declare to use another.
export PATH=$PATH:/opt/grails-selector
export GRAILS_HOME=/opt/grails-3.1.9
4- You're good to go. May you need to reopen your terminal or logout-login. When you call grails it will calls the grails.sh and then it looks for the version set in your project. So you it works automatically.