I have a project that is called "sportanalitica". When I run pipenv shell it enters the virtual environment and I see "(sportanalitica-KnWqfC-u)". Also if I install anything it says
Pipfile.lock (295b1e) out of date, updating to (74c969)…
Is there any solution or anything wrong?
No, nothing is wrong. That's just how pipenv works.
I run pipenv shell it enters the virtual environment and I see - (sportanalitica-KnWqfC-u)
That's just how pipenv names the virtual environment when it is created: <folder-name>-<hash>. That will also be an actual folder on your machine. See pipenv docs Virtualenv mapping caveat:
Pipenv automatically maps projects to their specific virtualenvs.
The virtualenv is stored globally with the name of the project’s root directory plus the hash of the full path to the project’s root (e.g., my_project-a3de50).
~$ mkdir sportanalitica
~$ cd sportanalitica/
sportanalitica$ pipenv shell
Creating a virtualenv for this project...
Pipfile: /Users/me/sportanalitica/Pipfile
...
✔ Successfully created virtual environment!
Virtualenv location: /Users/me/.venvs/sportanalitica-3tdk8qV0
Creating a Pipfile for this project...
...
(sportanalitica) sportanalitica$ pipenv --venv
/Users/me/.venvs/sportanalitica-3tdk8qV0
(sportanalitica) sportanalitica$ ll /Users/me/.venvs/sportanalitica-3tdk8qV0
total 8
drwxr-xr-x 23 cerberus staff 736B Dec 30 13:07 bin/
drwxr-xr-x 3 cerberus staff 96B Dec 30 13:07 lib/
-rw-r--r-- 1 cerberus staff 470B Dec 30 13:07 pyvenv.cfg
That's how pipenv knows that every time you run pipenv shell inside that same sportanalitica folder, it will find the existing sportanalitica-3tdk8qV0 virtual environment, and then you can just reuse it ever time.
if I install anything it says Pipfile.lock (295b1e) out of date, updating to (74c969)…
This is also part of pipenv's basic features. When you change something in your virtual environment (i.e. install a new package, uninstall a package, update a version), it will "compute" a new Pipfile.lock file to track the updates:
$ pipenv lock
$ 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.
The locking is automatically done when you pipenv install/pipenv uninstall. Locking is also part of pipenv's security features.
Basically, what you just did (pipenv shell + pipenv install) follows the Example Pipenv Workflow for pipenv. I recommend going through the Basic Usage of Pipenv docs.
Related
I ran pipenv install to create a Pipfile in the current directory that doesn't have a Pipfile. It gave the following output but did not create a Pipfile. Why not?
Installing dependencies from Pipfile.lock (639627)…
🐍 ▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉ 0/0 — 00:00:00
To activate this project's virtualenv, run pipenv shell.
Alternatively, run a command inside the virtualenv with pipenv run.
It looks like it found a Pipfile.lock somewhere and used it? (similar to git behavior)
Use the PIPENV_NO_INHERIT environment variable to ignore inheriting from directories above the current directory, e.g.,
PIPENV_NO_INHERIT=True pipenv install
In your case, pipenv searched directories above the current directory and found a Pipfile there that it used (the location of which can be seen with pipenv --where).
(Incidently, I looked at the pipenv documentation but was unable to find where it discussed this behavior, so please add a link here to that documentation if you find it.)
I ran pipenv shell first (creat Pipfile), then pipenv install (creat Pipfile.lock)
'pip install pipenv' command returns "Requirement already satisfied ..."
I see that bundle install and yarn install are usually done in Dockerfile as:
RUN bundle install && yarn install
Which means that if I modify Gemfile or yarn.lock, I need to re-build the image again. I know that there is layer caching and the docker build will not rebuild other layers except bundle install && yarn install layer. But it means I have to do docker-compose up -d --build
But I was wondering if it is ok to put these commands inside an entry script of docker-compose or in command as:
command: bundle install && yarn install && rails s
In this way, I believe, whenever I do docker-compose up -d, bundle install and yarn install will be executed without having to build the image.
Not sure if it has any advantages over conventional bundle install in Dockerfile except not having to append --build in docker-compose up. Correct that if I do this, bundle install and yarn install will get executed even when there are no changes to Gemfile or Yarn files. I guess this is one of the bad sides.
Please correct me if it is not the ideal way to go.
New to docker world.
It wastes several minutes of time and uses up network bandwidth every time you start your application. When you're doing local development, it'd be the equivalent of doing this, every time you run the application:
rm -rf vendor node_modules
bundle install # from scratch
yarn install # from scratch
bundle exec rails s
A core part of Docker is rebuilding images (in the same way that languages like Go, Java, Typescript, etc. have a "build" phase). Trying to avoid image rebuilds isn't usually advisable. With a well-written Dockerfile, and particularly for an interpreted language, running docker build should be fairly efficient.
The one important trick is to separately copy the files that specify dependencies, and the rest of your application. As soon as a Dockerfile COPY instruction encounters a file that's changed it will disable layer caching for the rest of the application. Since dependencies change relatively infrequently, a sequence that first copies the dependency file, then installs the dependencies, then copies the application can jump straight to the last step if the dependency file hasn't changed.
COPY Gemfile Gemfile.lock ./
RUN bundle install
COPY package.json yarn.lock ./
RUN yarn install
COPY . ./
(Make sure to include the Bundler vendor directory and the node_modules directory in a .dockerignore file so the last COPY step doesn't overwrite what previously got installed.)
This question is opinion based. As you already found out yourself, it is a common practice to install dependencies (bundle, yarn, others) during the image build process, and not image run process.
The rationale is that you run more times than you build, and you want the run operation to start quickly.
In the same way that you do apt install... or yum install... in the build stage, you should normally do bundle install in the build stage as well.
That said, if it makes sense to you to bundle install as a part of the entrypoint, that is your choice. I suspect that after you do it, you will see that it is less common for a reason.
Another note about docker layers: If the Gemfile change, not only the layer that refers to it will change, but all subsequent layers as well. For that reason, it is often common to separate the copy of the dependencies manifest (Gemfile.*) from the copying of the app, like this:
# Pre-install gems
COPY Gemfile* ./
RUN gem install bundler && \
bundle install --jobs=3 --retry=3
# Copy the rest of the app
COPY . .
So this way, if your app files change, but not the dependencies, the build will be faster.
Is it possible to tell pipenv where the venv is located? Perhaps there's something you can put in the pipfile, or something for the .env file?
I fairly frequently have to recreate my venv because pipenv seemingly loses track of where it is.
For example, I started a project using Pycharm to configure the file system and create my pipenv interpreter. It created the venv in ~/.local/share/virtualenvs/my-project-ZbEWMGNA and it was able to keep track of where that interpreter was located.
Switching to a terminal window & running pipenv commands then resulted in;
Warning: No virtualenv has been created for this project yet! Consider running pipenv install first to automatically generate one for you or seepipenv install --help for further instructions.
At which point I ran pipenv install from the terminal & pointed pycharm at that venv, so the path would become ~/apps/my-project-ZbEWMGNA (which sits alongside the project files ~/apps/my-project)
Now I've got venvs in both paths and pipenv still can't find them.
mwalker#Mac my-project % pipenv --where
/Users/mwalker/apps/my-project
mwalker#Mac my-project % pipenv --venv
No virtualenv has been created for this project yet!
Aborted!
mwalker#Mac my-project % ls ~/apps
my-project
my-project-ZbEWMGNA
mwalker#Mac my-project % ls ~/.local/share/virtualenvs
my-project-ZbEWMGNA
Yes, it is possible by setting environment variables. You can set a path for virtual environments via the WORKON_HOME. Or have the virtual environment created in the project with PIPENV_VENV_IN_PROJECT.
Pipenv automatically honors the WORKON_HOME environment variable, if you have it set — so you can tell pipenv to store your virtual environments wherever you want
-- https://pipenv-fork.readthedocs.io/en/latest/advanced.html#custom-virtual-environment-location
or
PIPENV_VENV_IN_PROJECT
If set, creates .venv in your project directory.
-- https://pipenv-fork.readthedocs.io/en/latest/advanced.html#pipenv.environments.PIPENV_VENV_IN_PROJECT
In my experience, PyCharm will uses the existing venv created by Pipenv. Otherwise it will create it in the directory that PyCharm is configured to create it.
I am new to pipenv so there might be something I'm not understanding here. However it seems like the virtual environment which is created depends on the current directory, which seems bad to me.
Here is what I did:
Checked out code from Github which already had Pipfile and Pipfile.lock
Did some unrelated stuff... at this point I was in a directory called /home/user/me/miniconda3/bin/
Ran /home/user/me/miniconda3/bin/pipenv run python /home/user/me/my-script-dir/my-script.py
This caused Pipenv to create a virtual environment. Output:
Creating a virtualenv for this project...
Using /home/user/me/miniconda3/bin/python (3.6.4) to create virtualenv…
Already using interpreter /home/user/me/miniconda3/bin/python
Using base prefix '/home/user/me/miniconda3'
New python executable in /home/user/me/.local/share/virtualenvs/bin-YnM8YhRk/bin/python
Installing setuptools, pip, wheel...done.
Virtualenv location: /home/user/me/.local/share/virtualenvs/bin-YnM8YhRk
Creating a Pipfile for this project…
Then I realized that I needed to run pipenv install so this time I cd'd to the directory where the script is actually stored, /home/user/me/my-script-dir/, and ran /home/user/me/miniconda3/bin/pipenv install. Then I got this output:
Creating a virtualenv for this project…
Using /home/user/me/miniconda3/bin/python (3.6.4) to create virtualenv…
Already using interpreter /home/user/me/miniconda3/bin/python
Using base prefix '/home/user/me/miniconda3'
New python executable in /home/user/me/.local/share/virtualenvs/my-script-dir-Ex37BY7g/bin/python
Installing setuptools, pip, wheel...done.
Virtualenv location: /home/user/me/.local/share/virtualenvs/my-script-dir-Ex37BY7g
Installing dependencies from Pipfile.lock (6c24e4)…
So as you can see I actually was running the same script each time, but somehow it created two different virtual environments. And the virtual environments are named after what happened to be my current directory at the time, not the directory of the script. This seems like it would be very unwieldy unless I am missing something.
You are correct, the virtualenv Pipenv uses does depend on the current directory.
I'm trying to install Jenkins on a Tomcat 7 container.
When I try to open the Jenkins web app I get following error:
Unable to create the home directory '/home/myuser/jenkins/work'. This is most
likely a permission problem.
To change the home directory, use JENKINS_HOME environment variable or set
the JENKINS_HOME system property. See Container-specific documentation for
more details of how to do this.
Before starting Tomcat, I did chmod uog+rwx /home/myuser/jenkins. So, I suppose that Jenkins should be able to create a subdirectory there.
But obviously it can't.
How can I fix this problem?
Update 1:
lt -lt returns
drwxrwxrwx 2 root ec2-user 4096 Jun 23 10:25 jenkins
for /home/myuser/jenkins. /home/myuser/jenkins/work doesn't exist because Jenkins is supposed to create it.
Update 2: Just tried to create the work directory and to run chmod uog+rwx on it. It didn't help.
Update 3: Additional information:
I need Jenkins in order to
run lengthy tests in the night (fast unit tests are run before every mvn install, slow tests are executed every night) and
save software quality metrics (checkstyle, PMD, FindBugs, unit test coverage etc.) over time.
I have only one machine available for that and there is a Tomcat7 container installed there already.
At the moment, I don't want to invest additional money into buying new machines.
The machine with the Tomcat7 container (and where I want Jenkins to be installed) is an Amazon EC2 microinstance (OS version is given below).
$ cat /etc/*-release
LSB_VERSION=base-4.0-amd64:base-4.0-noarch:core-4.0-amd64:core-4.0-noarch:printing-4.0-amd64:printing-4.0-noarch
Amazon Linux AMI release 2013.03
Update 4 (29.06.2013 13:34 MSK): The output of yum list does not contain any Jenkins/Hudson package.
If Tomcat is running as a separate user you will need to give execute permission to your home directory to that user - either by giving it to all or by creating a group especially for you and the tomcat user.
(UPDATE) More specifically: You say you already did chmod uog+rwx /home/myuser/jenkins, if Tomcat is not running asl 'myuser' it also needs execute permission on /home and on /home/myuser to be able to open /home/myuser/jenkins. If you are not picky about other users on the system opening your homedir you could allow this by: chmod a+x /home/myuser. (I'm assuming here the permissions for /home are already ok)
If you are running tomcat as 'myuser' the filsystem permissions look fine, but Tomcat's own permission system might be the problem as webapps are not allowed to touch the filesystem if the default settings of the security manager are on.
See: https://wiki.jenkins-ci.org/display/JENKINS/Tomcat
You don't specify more about your exact Tomcat/OS setup so I can't give exact details, but the fast way to find out if it's a security manager issue is to give AllPermission to you webapp. If you don't run in a safe environment it is advisable to only use that as a test, and setup only the really needed permissions later.
run these three commands
cd /usr/share/tomcat7
sudo mkdir .jenkins
sudo chown tomcat7:nogroup .jenkins
https://seleniumwithjavapython.wordpress.com/home/jenkins-installation/
It looks like the problem may be that jenkins cannot see /home/myuser, and therefore it cannot access the jenkins folder inside this (even though it has write permissions in /home/myuser/jenkins, I believe the fact it can't read /home/myuser causes a problem).
Try running the below command and then see if Jenkins works after that:
chmod +r /home/myuser
#robjohncox Yes - drwx------ 5 myuser myuser 4096 Jun 23 10:25 myuser
you must add +x to this dir to make it possible for jenkins to access it's contents, to be precise whole path has to have +x enabled for everyone.
Also, what commands have you used to move it's home dir from default - possible error is somwhere there. Cheers, Piotr