In the origen docs it says that the gems are installed in the user's home directory. Can this be configured by each user?
EDIT *
I placed a copy of the origen_site_config.yml file in my application's root directory and enabled the following line:
# Define where a typical user's home directory will be, with a hidden directory for Origen.
home_dir: /users/thisuser/origen
I expected this to work and start installing at /users/thisuser/origen/.origen but it did not. I deleted the .bundle and lbin directories and got no change in the installation directory either.
thx
This question prompted a PR and some new documentation on how to change the install directory of gems within Origen.
I haven't ever tried it but you should be able to override the install using the site_config.
Ruby/Bundler will by default install gems into the Ruby installation directory.
However, since it is commonplace in corporate engineering compute environments for users to share a common Ruby installation to which they don't have write access, Origen provides a default Bundler configuration which will instead install gems to the user's home directory.
This install location is defined by the gem_install_dir attribute of the Origen Site Config.
This can be overridden on a company level in the master site config, however this is (currently at least) a static variable, so the only way to make it user specific is to reference $HOME or some similar Linux-level variable used within the given environment.
It is possible to have all users share a gem installation directory, however the downside to that is that all users will need to have write access to it and therefore potentially a hack to a gem source by one user could end up introducing a very hard to detect bug that affects the whole company.
Better then, is to override on a per-user basis if you don't like filling up your home directory with gem files.
Here are the various ways to do that:
1) Any site config variable can be overridden by setting an environment variable named ORIGEN_<uppercased variable name>, so ORIGEN_GEM_INSTALL_DIR in this case.
2) Symlink $HOME/.origen to somewhere else.
3) Users can use their own site config file. See the guide for more details, but Origen will search multiple places for a config and parameters defined in configs which are closest to where the application lives will override more distant defaults. So for example, say a user kept all of their Origen workspaces in /my_projects/origen/, e.g. /my_projects/origen/my_app, then anything config attributes defined in /my_projects/origen/origen_site_config.yml would override those set at the company-level.
Bundler will cache this configuration on a per-workspace basis, so anytime you make changes to a configuration like this it is recommended to either start with a fresh workspace, or run the fix_my_workspace script.
Related
I launched an appimage using appimagelauncher. Then, I modified some settings of that app.
I know that appimages are not installed, so it can't be uninstalled. So, I deleted the appimage file.
But, when I downlaoded the appimage again, I observed that the user's previously modified settings were still there.
Now, how can I completely remove those user modified settings and launch that software as if it were newly installed?
The AppImage format doesn't define an explicit place where the applications configuration should be installed. Which means that the application can write such file wherever they please (as a regular installed application does).
Applications usually write their configurations to "$HOME/.config", you can look there for a file or folder with the application name. You can also ask the application author or check the documentation.
I'm working on 2 different machines (home vs. work) and transfer the code via GitHub, which works nice, but I just ran into a machine dependency when I added this code to the gradle.properties file to fix a vexing OAuth issue for google sheets:
org.gradle.java.home=C:\Program Files\Java\jdk1.8.0_131
org.gradle.java.home=C:\Program Files\Java\jdk1.8.0_77
Now I have to toggle between the 2 lines to get Gradle to compile. Need to check if I still need it (since I got the keystore files etc. sorted out), but I also wonder whether there is an easy solution to make this work (e.g. something like ifdef).
Obviously, I could just change the directory name in one of the machines I guess, but still curious how to solve this within Studio.
Lets start with a quote from the Gradle docs:
org.gradle.java.home
Specifies the Java home for the Gradle build process. The value can be set to either a jdk or jre location, however, depending on what your build does, jdk is safer. A reasonable default is used if the setting is unspecified.
So, by default, you should not need this project property (thats what they are called in Gradle).
However, there can be reasons, that you need to specify the Java directory. For this specific project property, you can follow Ray Tayeks advice and use the JAVA_HOME environment variable (on both systems). But there is also another approach, which can be used for any project property (and also for so-called system properties):
gradle.properties files can be located at different locations of the file system. Your files are located in the project directory and, therefor, they are included in your VCS. You can use them / it for project-related properties. An additional location is in the Gradle user home directory, which is by default the .gradle folder in your personal folder. This folder is not under version control, so simply define the property there.
try removing the line from the properties file. if that fails, try setting JAVA_HOME on each machine.
there are a lot of related questions.
you might try asking on the gradle forums.
I have been trying to use GoClipse (0.8.1v2001409161333 - latest available from the goclipse_feature.feature.group) with Eclipse (4.4.2) on Linux (CentOS6.6) with GO (1.4.2-2.el6) installed via yum from EPEL and have only achieved partial functionality.
Intellisense appears to work fine for the built in packages but GoClipse appears to do something weird with it's directory structure that is different from the normal GO workspace layout. The existing structure under source control looks like:
$GOPATH/bin/...
$GOPATH/pkg/...
$GOPATH/src/externalsite/module/version/*.go
$GOPATH/src/externalsite/module/version/subdir/*.go
$GOPATH/src/me/module/*.go
$GOPATH/src/me/module/feature/*.go
When I try and use GoClipse it always appears to insist that the *.go files must be a peer of the bin|pkg|src directories. This means that I either have my *.go files at $GOPATH or tell GoClipse where main.go is ($GOPATH/src/me/module/main.go) and GoClipse creates the bin|pkg|src directories again:
$GOPATH/src/me/module/bin/
$GOPATH/src/me/module/pkg/
$GOPATH/src/me/module/src/
My GoClipse configuration has $GOPATH set appropriately (I have tried with $GOROOT undefined or set to the yum install location to no effect) and when creating the Go project from existing code specifying the location as $GOPATH/src/me/module/ (manually expanding $GOPATH)
Some resources that I have located do not appear to offer any advice on getting GoClipse to respect the proper go workspace structure and I am hoping someone can tell me how to do this.
The following resources might be of interest but they do not solve this difficulty:
How to run a GO project in eclipse with goclipse installed
https://github.com/GoClipse/goclipse
Indeed, goclipse.github.io/releases is the latest update site URL, so you should use the latest version (the URL did change several times since in the span of the previous year). The way Goclipse handles the Go enviroment has changed significantly since 0.8.0, particularly with 0.9.0, which allows creating an Eclipse project on a folder inside a GOPATH 'src' entry. (and other cases are handled better, especially with the builder).
Note: you will need to recreate your Eclipse Go projects after updating (0.10.0 had some internal, non backward-compatible changes).
You might want to consult the changelog for more details: https://github.com/GoClipse/goclipse/releases
I'll try to keep this question short, but it is in 2 parts, please:
Where should config files for nodejs/npm CLI tools be saved?
What should they be called?
Let's say I write a node.js CLI tool that, for example, grabs today's weather and displays it in terminal. I call it weather-getter. Note, the main goal is not to be called programmatically, but typed into terminal like BASH. It is intended to be run by typing its simple name after installing globally, or via a directory in the user's local /bin. (Sudo is not required for its install.)
This project would be installed normally via npm. It can receive a zipcode via an argument like:
gavin#localhost:~$ weather-getter -z "12345"
OK the program works fine like this. My next step would be to allow the user to save a config file somewhere, and pull from that config file for defaults. Similar to a .vimrc file. This config might look like this:
{
"zipcode": "12345",
"language": "en",
"unit": "fahrenheit"
}
I suppose it should begin with a dot. I also suppose it should be located in the npm module install, and not in ~/. Or should I consider using ~/ or /etc/ or ~/.config or ~/.local like many other programs? Should node programs try to use a common directory, such as ~/.config/node/ or ~/.config/npm/? And if the file is in there, should it begin without the dot?
Note: My question is not about reading/writing a file with node.js, just recommendations on the config location and naming convention. Thank you!
Since this is a generic CLI application (which only so happens to be implemented in Node.js) installed into the system path, you should follow the best practices or rules established for the target operating system.
Unix/Linux/OS X, similar
In order of priority, these would be (but are not limited to):
~ (User's home folder) - many programs store user-level config in their home directory, usually in a dot-prefixed file, followed by the application's name (or similar) - i.e. ~/.weather-getter
/usr/local/etc, /etc - system-level configuration files. These should generally apply to all users in the system and thus should take less precedence than settings in home folder. The difference between these two etc paths is usually that the former is used for user-installed programs, whereas the latter is for system-level programs (this is especially true for Mac users using Homebrew). This distinction is, however, not always respected and therefore both locations should be checked for config files (preferrably with the /etc directory having lesser priority).
Your application's root - these should be the default settings for your application, a fallback when no user or system config has been found.
Other locations may be considered if needed.
Windows
This is usually somewhere within %APPDATA% directory if your app allows GUI or at least CLI configuration management, or the Windows registry (using winreg, for example). I have personally little experience with Windows development/CLI so I welcome any further comments or answers on this topic. I believe using the user's homefolder would also be acceptable as long as the file can be marked as hidden (so it does not clutter the view).
Some general considerations
Many CLI applications install their default configurations into one of the mentioned locations so the user has a good starting point when configuring your app
The way your configuration options are treated when multiple configuration files are present (are they merged in some order? Is only one used? Which one takes precedence?) is completely up to you, but you should make it clear in your documentation, perhaps even mention it in the configuration files themselves
If your application requires multiple configuration files it is preferred that they are grouped in their own folder
Update about dotfiles
The reason why some files or folders are prefixed with a dot is to hide them from users' normal view (i.e. when browsing their home directory via a GUI). It is therefore common practice to use dot-prefixed file/folder names when storing configuration files in directories where users normally operate, but not do so when storing config files in system-level folders.
The ospath package has a function data() which returns a sensible location for such files for each of the major platforms.
I'm preparing to update my Eclipse to 4.2 version and I'd like to solve one problem that has been annoying me since many many years. Right now my installation looks like this:
eclipse folder is located in /usr/local/share. This is a system-wide directory, yet Eclipse requires write permissions for a user, which goes against unix permissions philosophy.
I have a workspace and all plugins that I install go into .metadata folder within this workspace.
What I'd like to achieve is:
first of all, do not install plugins in the workspace directory. I'd like to see plugins installed either somewhere in my home directory or - if it is necessary for the user to have write permissions to eclipse directory - in eclipse directory itself.
take away users write permissions for eclipse directory. This will of course prevent installing plugins there, but I won't mind installing them somewhere in ~
preferable solution would be to take away write permissions for the user to eclipse directory and be able to install plugins within that directory as root. So when I want to add new plugin, I start Eclipse with root privileges, install the plugin (it goes to eclipse installation directory) and then I can use this plugin as non-privileged user.
Although I'm not a linux user, I'm 99% certain that plugins will never be installed into a workspace; that's just contrary to how workspaces and plugins are separated in Eclipse's architecture. A workspace may have configuration/cache data that is stored with file/folder names resembling plugin names, but the actual plugins are stored elsewhere.
I think if you read the multi-user install guide from the online help, you'll find one of the options outlined there will suit your needs.
Take a look at the shared install documentation for instructions on how to setup a base eclipse that a user doesn't have write access to and allow user-local install of plugins.
http://help.eclipse.org/indigo/index.jsp?topic=%2Forg.eclipse.platform.doc.isv%2Freference%2Fmisc%2Fmulti_user_installs.html