The official way of working with expo-cli is to install it globally, see https://docs.expo.io/get-started/installation/#installing-expo-cli:
Installing Expo CLI
# Install command line tools
npm install --global expo-cli
However, I never found any explanation about why it is supposed to be global (other than that this simplifies the initial expo init command). To my thinking, having a global package undermines the whole idea behind npm and local node_modules. Essentially, expo-cli is a direct dependency of the project. It's used for running the dev version with expo start and also for creating production builds.
Different versions of expo-cli will work differently, they may even expect different values in app.config.ts. That means it's not safe to upgrade expo-cli globally for one project and then return working with an older project which has been created and maintained with an older version of (global) expo-cli.
None of this would have happened if expo-cli were a normal local project dependency like expo (the SDK package).
So, my question is: is there a real reason for keeping expo-cli global? What do I lose if I move it to local project dependencies? How come Expo documentation never even mentions such option?
Related
Lately, the mechanism used by Spack to manage the modules (I refer to the Environment Modules and to LMod) changed a little bit to allow a better integration with the spack environments (see pull request #23703).
Unfortunately, this also affect the fact that Spack does not update anymore the MODULE_PATH variable by default; indeed, the documentation still reports that
If you have installed a supported module system you should be able to run either module avail or use -l spack to see what module files have been installed.
but, at least on my machine, after installing a few packages, the module avail command does not show any new module (I am using commit 9936182). I suppose that this happens because now Spack want to know which environment should be loaded.
Of course,the problem could be easily fixed by adding the directory with the modules in the MODULE_PATH env var, but I am not sure that this is the best practice.
Is there a way to say to spack: "please, load the modules of the default environment?"
Thank you
I've been using stylelint-gulp for some time now without issue.
I have stylelint loaded as a npm devDependancy(ie not global, as I dont want it to be global) in my project, and following the instructions I should have the CLI available as well.
however stylelint --help returns "command not found"
I have other modules installed like eslint, and the cli works just fine.
node: v12.11.1
npm: 6.11.3
I also have nvm installed so I've tried switching back to npm --lts but it's still not working. Btw, this is on osx 10.13.6 if it matters.
any advice?
As you don't have stylelint installed globally you won't have the stylelint command available globally.
Similar to noted in the comment above, the best way to use the stylelint command when you don't have it installed globally is to access it via a repo where you do have it installed:
./node_modules/.bin/stylelint "**/*.css"
The short answer:
With any locally installed npm package (ie as a project's devDependancy), you should not expect to be able to run the package's CLI as follows <package_name> --help. You will need to include the full path to the module in the .node_moduels/ directory, just as #netweb has shown in his answer:
./node_modules/.bin/stylelint --help
IMHO Stylelint's documentation page is a tad confusing in this regard, which is why I asked the question.
The longer answer:
To be able to run stylelint --help or any other npm CLI, you would have to† install the package globally, ie: <package_name> -global. In that process, a symlink is created so the <package_name> keyword could be invoked in any directory on the system.
However, there is a category of tools (for example linters) where its usually considered bad practice to install them globally. This is because different projects will likely have conflicting requirements, in which case, having all these tools globally installed quickly becomes problematic. It's best to have these tools installed at the project level as a devDependancy like so: npm install <package_name> --save-dev.
If you are setting up an npm scripts or Continuous Integration systems then you would invoke these tools' CLI by including the path to the local install: ./node_modules/.bin/stylelint "**/*.css"
However, in the terminal, writing the fill path each and every time you want to invoke a tool is painful, so instead, you can use [npx][4] to invoke the locally installed module:
npx stylelint --help
† npm-link, also symlinks your local package as if it was a globally installed. However, except for some specific scenarios, it's very unlikely you want to make globally available a local devDependancy.
I need to install SUMO 0.30.0 to be used with the VEINS_INET subproject in veins 4.6. I have tried following the instructions here and suggestions from forums but haven't had any luck being able to install sumo. I run ./configure (trying various tool/library options) then run sudo make but all I get is target marouter failed or nothing to be done for 'install-exec-am' 'install-data-am'.
Does anyone know how to install sumo-0.30.0 from source and/or make the veins_inet subproject work with the latest version of sumo-0.32.0?
Don't run sudo make.
Don't run sudo make.
Your problem is probably related to a dependency/packaging change in 16.04, which is explicitly pointed out in the veins tutorial:
Note that Ubuntu 16.04 no longer includes libproj0; this can be worked around by temporarily adding the packet repository of, e.g., Ubuntu Vivid when installing this package.
Short answer: Unfortunately this means that long-term, you're going to either have to package SUMO yourself, use the versions someone else compiled (see this launchpad for example) or rely on an old version.
Long answer:
In general, I would recommend building SUMO from source by building its' dependencies from source, since I've encountered this problem on various distributions. In particular, the fox, proj and gdal libraries tend to be packaged in different versions, and along with changes in the SUMO source code. I currently use this script (with the package versions downloaded) to compile SUMO -- but this is for 0.30.0, and it breaks if any of the referenced source packages are moved (which happens quite often). My general recommendation would be to either use a completely isolated version of SUMO (i.e., compiling by hand as much as possible) or relying on a pre-packaged version (see above), as long as that version is recent enough to work with VEINS.
When using the version of fastlane installed from Homebrew, I don't know how to use a development build of a plugin. I see fastlane add_plugin still generates a Pluginfile. If I try adding gem "fastlane-plugin-xxx", git: "https://github.com/yyy/xxx" or something similar using a :path argument, it always tries to install the version from RubyGems.
I have two specific cases where this makes things inconvenient:
I'm building a new plugin for a client. I want mobile devs to review it internally before it is published.
A user reported an error from a published plugin. I want them to try a dev version from the master branch in order to get more information.
In both cases, I think it's necessary to use Ruby and the Bundler. Not everyone has lots of Ruby experience, so getting someone set up can be an obstacle.
Edited 2017-07-06:
Part of the answer is obvious. When you run fastlane add_plugin, it prompts you if it cannot find the gem:
[jdee#Jimmy-Dees-MacBookPro TestApp]$ fastlane add_plugin my_new_action
[10:46:28]: Seems like the plugin is not available on RubyGems, what do you want to do?
1. Git URL
2. Local Path
3. RubyGems.org ('fastlane-plugin-my_new_action' seems to not be available there)
?
This works well with the fastlane gem, e.g. with RVM:
gem install fastlane
fastlane add_plugin my_new_action
The self-contained binary from Homebrew also prompts you for a Git URL or a local path, but I consistently get build failures from native extensions in the json gem on OS X Sierra. This may be due to plugin dependencies, but I'm not sure. This can still be a little awkward for the use cases above, and I'm surprised that this fails with the self-contained version, which I'd expect to be more robust than using Ruby. At least this removes the need for bundle install and bundle exec.
The answer here is basically that the self-contained version of Fastlane does not really work with plugins. In particular, when fastlane add_plugin or fastlane install_plugins runs bundle install, it tries to install the json gem, a dependency of the fastlane gem, which has native dependencies, and it cannot find <stdio.h>, presumably because /usr/include is screened out in the self-contained bundle in order to insulate it from the system Ruby. After this, you can run bundle install and bundle exec yourself, but in general a Gemfile is required to work with Fastlane plugins. The CLI will even tell you to run bundle exec once you have a Gemfile.
When using the fastlane gem, fastlane add_plugin will usually work, but again you will have a Gemfile and want to run bundle exec fastlane afterward.
You can just modify your Pluginfile to use a path or a git repo and rerun bundle install. There's not a much easier way to do this at the moment.
system : MAC OS 10.11.6
The error message :
Error: could not connect to website
(url->port: bad reply from server: #<eof>)
I don't know if I can simply drag the "Racket v6.2.1" folder in Application to Trash and then install the newest version of DrRacket.
This was, unfortunately, a bug in Racket that was present in v6.2.1. It has since been fixed (by me, in this commit), but given that you have a version with the bug, you’ll have to update it manually.
Each installation of Racket basically exists within its own sandbox, though, so you should be able to install the new version alongside v6.2.1 without any problems, and you can check if it works. Things like settings will be preserved across versions, but installed packages will not be.
I think DrRacket may prompt you to migrate your packages when you launch a new version, but I honestly forget. However, you can manually migrate your old packages from another version using the raco pkg migrate command. Otherwise, it’s not much of a loss—you can always just reinstall them.
Once you’ve migrated your packages (or decided you don’t want or need to), you can safely delete your old installation’s directory.