According to the documentation:
pipenv install foo==0.x
will install foo with the specified version and update both Pipfile and Pipfile.lock.
If the foo has been written into both files, then what is the need for pipenv lock command?
The document said it:
Regenarate Pipfile.lock and updates the dependencies inside it.
Under what situation do we need to call the pipenv lock command?
Thanks if you could clarify my confusion.
As I understand, it can be used to update all your dependencies before entering production.
pipenv lock is used to create a Pipfile.lock, which declares all dependencies (and sub-dependencies) of your project, their latest available versions, and the current hashes for the downloaded files. This ensures repeatable, and most importantly deterministic, builds.
You can use pipenv lock to compile your dependencies on your development environment and deploy the compiled Pipfile.lock to all of your production environments for reproducible builds.
Related
I am using npm version 7.18.1. From what I see from the documentation the --only=development option no longer exists.
I'm creating a multi-stage Docker image. What I need to do is to create an image for the development step in which only devDependency packages are installed. On the next step, I'm going to create another image with production packages installed in it.
How do I do this without the --only=development option?
I am new to dockers, well we started working on docker file but I am stuck on how to maintain different versions of dependent software's of our web app.
suppose our web app uses crystal reports 1.X version, in runtime.
In future , if want to update version of crystal report to 1.2.X.
In these scenarios how a docker file and these dependent software's should be maintained(although version we can directly update in docker file)?
Should docker file be parametrised for the versions?
What would be the best approach?
Use your application language's native package dependency system (a Ruby Gemfile, Python Pipfile or requirements.txt, Node package.json, Scala build.sbt, ...). In a non-Docker development environment, maintain these dependencies the same way you would without Docker. When you go to translate this into a Dockerfile, copy these description files into the image and install them.
A near-universal Javascript Dockerfile, for example, would look like
FROM node:12
WORKDIR /app
# Copy in and install dependencies
COPY package.json yarn.lock .
RUN yarn install
# Copy in the rest of the application; build and set up to run it
COPY . .
RUN yarn build
EXPOSE 3000
CMD yarn start
If a dependency changed, you'd use a command like yarn up to update the package.json and yarn.lock files in your non-Docker development environment, and when you went to re-docker build, those updated files would update the dependency in the built image.
What are the best practices when using development modules such as Mocha or Browserify, which are needed during the build process but not in the built artifact itself? The only options I can see are:
Pre-arranging these modules to be installed globally on the build server (not likely possible in my case)
Run npm install -g explicitly as part of the build process for each module (Feels somewhat wrong to install globally)
Don't use the --production flag on npm install (which forces these modules to be present in the final artifact, increasing its size and defeating the purpose of dev/production dependencies)
I have a lot of devdepencencies in my npm script. npm install takes a few minutes the first time, that's ok.
But since I'm integrating with TFS build server, it only needs to npm install once. After that, npm install is just wasting time because it takes 2-3 minutes to just determin the packages are already installed. Also, it seems to always reinstall the packages with -g global flag, even when existing.
How can I make it check if packages exist, and if so, skip npm install?
You can use npm-cache as an alternative way if you use on-premise build agents for build.
It is useful for build processes that run [npm|bower|composer|jspm]
install every time as part of their build process. Since dependencies
don't change often, this often means slower build times. npm-cache
helps alleviate this problem by caching previously installed
dependencies on the build machine. npm-cache can be a drop-in
replacement for any build script that runs [npm|bower|composer|jspm]
install.
How it Works
When you run npm-cache install [npm|bower|jspm|composer], it first
looks for package.json, bower.json, or composer.json in the current
working directory depending on which dependency manager is requested.
It then calculates the MD5 hash of the configuration file and looks
for a filed named .tar.gz in the cache directory ($HOME/.package_cache
by default). If the file does not exist, npm-cache uses the system's
installed dependency manager to install the dependencies. Once the
dependencies are installed, npm-cache tars the newly downloaded
dependencies and stores them in the cache directory. The next time
npm-cache runs and sees the same config file, it will find the tarball
in the cache directory and untar the dependencies in the current
working directory.
And you can also try with npm-install-missing.
However, if you are using VSTS Hosted Build Agent, then you cannot do this since every time you queue a build with Hosted Build Agent, a clean build agent is assigned for the build. That means there is no dependency package installed on the agent. You need to perform a complete npm install.
What is the difference? I realise that they get put into different object properties in bower.json but I can't seem to figure out why you need two separate properties for this, why not just use one.
From the documentation:
-S, --save: Save installed packages into the project’s bower.json dependencies
-D, --save-dev: Save installed packages into the project’s bower.json devDependencies
But there is no explanation of the difference between the two. When should I be saving in dependencies vs devDependencies?
Same case than in npm. Packages that you use in production should go inside dependencies and those that do not inside devDependencies.
The idea is that you are able to install only --production or --development variables, depending on the environment you are deploying your code.
From another answer in this community: What's the difference between dependencies, devDependencies and peerDependencies in npm package.json file?