I have a Cloud9 space and I have a small app running. Currently I am trying to start the Rethink service and its not working. I installed rethink using
npm install rethink -g --save
and I then type
rethink
to try and start the server, and it tells me
bash: rethink: command not found
what am I doing wrong? It seems pretty straight forward yet its not.
Not everything can be installed via npm, as its name suggests (Node Package Manager), it's mainly for Node.js packages and programs. RethinkDB is primarily written in C++, and its tooling is written in Python.
The rethink NPM package is an ODM (Object Document Mapper, similar to an ORM) one of the few Node.js packages which allow your Node.js program to interface with the database. Refer to it here: https://www.npmjs.com/package/rethink
To install RethinkDB on Cloud9, follow the instructions for installing RethinkDB on Ubuntu here: https://www.rethinkdb.com/docs/install/ubuntu/. You only need to follow the section that says "With binaries".
Related
I'm using a Macbook M1 for development. When I try to deploy my serverless application to AWS I'm running into this error:
I'm using the aws-nodejs-typescript template.
You installed esbuild for another platform than the one you're currently using.
This won't work because esbuild is written with native code and needs to
install a platform-specific binary executable.
Specifically the "esbuild-darwin-arm64" package is present but this platform
needs the "esbuild-darwin-64" package instead. People often get into this
situation by installing esbuild with npm running inside of Rosetta 2 and then
trying to use it with node running outside of Rosetta 2, or vice versa (Rosetta
2 is Apple's on-the-fly x86_64-to-arm64 translation service).
If you are installing with npm, you can try ensuring that both npm and node are
not running under Rosetta 2 and then reinstalling esbuild. This likely involves
changing how you installed npm and/or node. For example, installing node with
the universal installer here should work: https://nodejs.org/en/download/. Or
you could consider using yarn instead of npm which has built-in support for
installing a package on multiple platforms simultaneously.
If you are installing with yarn, you can try listing both "arm64" and "x64"
in your ".yarnrc.yml" file using the "supportedArchitectures" feature:
https://yarnpkg.com/configuration/yarnrc/#supportedArchitectures
Keep in mind that this means multiple copies of esbuild will be present.
Another alternative is to use the "esbuild-wasm" package instead, which works
the same way on all platforms. But it comes with a heavy performance cost and
can sometimes be 10x slower than the "esbuild" package, so you may also not
want to do that.
Why is this happening?
I needed to reinstall serverlesss....
for that I deleted the folder ./serverless in the directory ~
and reinstalled using homebrew
https://formulae.brew.sh/formula/serverless#default
I am following a Microservices course that creates a free NMP account and pushes a package he writes through the course into it and imports this package in other related files of the application like a common NPM module/package.
He also mentions there are other options like using Github or some local Git/version controller, etc.
As I am trying to make a commercial project for my own startup, I am curious to know what is a good/affordable option for a startup company in this situation? Is is still a good idea to use NPM free public account to push some packages and use it through our application?
I think that if you are creating a module that can be useful to the community or part of it, NPM is an interesting option to keep your packages.
If you're uploading not usable packages, but your whole application to npm, then that's messed up, NPM is a package registry. Github, Gitlab, and tools alike should be a more suitable option since those are general-purpose code repositories, not package registries.
Also, be aware that the packages you upload on a free npm account are available to any NPM user. see: NPM Private Packages
From my previous experience, both GitLab and Github offer good free small professional accounts that may be suitable for your case.
I recently got confused and almost installed a tool via brew install when in fact it was an npm package and all I needed to do was npm install -g.
So these tools are strangely similar yet obviously different.
What's the difference in crystal clarity?
NPM exists to resolve dependencies for application code, on a per app basis, allowing an app to be self-contained and portable. This means that (in its default mode of operation) it will install the same stuff many times, uniquely, repeatedly, and separately, for every app on your system that needs the same package, inside of that apps own directory and isolated from everything else.
Homebrew is not like this. The reason is it serves the system itself, not individual apps, so is more comparable to just the npm -g part of npm.
There is one extra bit to understand about homebrew, though - some system packages have specific dependencies and could even have conflicts. This means that for the global installs that homebrew provides, it also has to solve some nesting and conflict issues. It's a kind of magic?
I don't know how it got this bad. I'm a web developer, and I use Ubuntu, and here are just some of the package managers I'm using.
apt-get for system-wide packages
npm for node packages
pip for python packages
pip3 for python 3 packages
cabal for haskell packages
composer for php packages
bower for front-end packages
gem for ruby packages
git for other things
When I start a new project on a new VM, I have to install seemingly a dozen package managers from a dozen different places, and use them all to create a development environment. This is just getting out of control.
I've discovered that I can basically avoid installing and using pip/pip3 just by installing python packages from apt, like sudo apt-get install python3-some-library. This saves from having to use one package manager. That's awesome. But then I'm stuck with the Ubuntu versions of those packages, which are often really old.
What I'm wondering is, is there a meta-package manager that can help me to replace a few of these parts, so my dev environment is not so tricky to replicate?
I had a thought to make a package manager to rule them all for that very reason. Never finished it though, too much effort required to stay compatible. For each package manager you have a huge community supporting it's upkeep.
Best advice I have is to try to reduce your toolchain for each type of project. Ideally you shouldn't need to work in every language you know for each project you work on. How many projects are you using that use both python 2 and python 3 simultaneously?
Keep using apt for your system packages and install git with it. From there try to stick to one language per project. AFAIK all of the package managers you listed support installing packages from git. The languages you mentioned all have comparable sets of tooling, so use the toolchain available for the target language.
I worked with a team that was using composer, npm, bower, bundler, maven, and a tar.gz file for frontend SPAs because those are the tools they knew. On top of all of that, they were using vagrant simply as a deployer. We considered our toolchain and described our need and realized that it could be expressed in a single language once we adopted appropriate tooling for the task at hand.
Can someone explain to me the difference between NPM, Bower and Composer.
They are all package managers - correct?
But when should each one be used?
Also, each one appears to have a json file that accompanies it, does this store all the packages you require so they can be installed by cmd line? Why do you need this file?
[update, four years later]
bower is deprecated, and should not be used anymore for new projects. To a large extent, it has been subsumed into node dependency management (from their website: "While Bower is maintained, we recommend using Yarn and Webpack or Parcel for front-end projects").
yarn came out of the wood as a better npm (fixing several of npm flaws), and this is really what you should use now, as it is the new de-facto standard if you are doing front-end or node development. It does consume the same package.json as npm, and is almost entirely compatible with it.
I wouldn't use composer at this point (because I wouldn't use php), although it seems to still be alive and popular
[original answer]
npm is nodejs package manager. It therefore targets nodejs environments, which usually means server-side nodejs projects or command-line projects (bower itself is a npm package). If you are going to do anything with nodejs, then you are going to use npm.
bower is a package manager that aims at (front-end) web projects. You need npm and nodejs to install bower and to execute it, though bower packages are not meant specifically for nodejs, but rather for the "browser" environment.
composer is a dependency manager that targets php projects. If you are doing something with symfony (or plain old php), this is likely the way to go
Summing it up:
doing node? you do npm
doing php? try composer
front-end javascript? try bower
And yes, the "json" files describe basic package information and dependencies. And yes, they are needed.
Now, what about the READMEs? :-)
https://github.com/bower/bower
https://www.npmjs.org/doc/cli/npm.html
https://getcomposer.org/doc/00-intro.md