DistributionNotFound when running pserve with docker-compose
I’m trying to run my simple Pyramid application with docker-compose, below are my docker files:
FROM python:2.7-onbuild RUN pip install --no-cache-dir -r requirements_dev.txt
db: image: mysql:5.6 web: build: . command: pserve development.ini --reload volumes: - .:/usr/src/app ports: - "6543:6543" links: - db:db
When I run
docker-compose up I get
pkg_resources.DistributionNotFound: The 'tenders' distribution was not found and is required by the application, which is weird, because my application should have been installed using by
pip install -e . command.
Things are getting weirder:
docker-compose run web bash root@2323b6b2f3ca:/tenders# pip freeze | grep tenders # no results root@2323b6b2f3ca:/tenders# pip install -e . Obtaining file:///tenders # Skippping most of the outup for more readability Installing collected packages: tenders Running setup.py develop for tenders Successfully installed tenders root@2323b6b2f3ca:/tenders# pip freeze | grep tenders -e firstname.lastname@example.org:xxx/tenders.git@342a8f9101a3e06fa04d71f4eef81b461476d3a5#egg=tenders-master
Now when I launch
pserve development.ini --reload it works just fine.
What am I doing wrong, how can I install my package
tenders automatically using
pip install -e . (or any other command)?
One Solution collect form web for “DistributionNotFound when running pserve with docker-compose”
I had the same problem. It happens when the docker volume is mounted.
In your Dockerfile, you install the application with
pip install -e ., which creates the .egg-info directory in the current directory (in the image). But later, when you use the docker volumes to replace the container source directory with yours, you don’t have this .egg-info directory in your host filesystem.
The way I fixed it is that I created a virtualenv in my host filesystem, I ran
python setup.py develop, but I guess you could run
pip install -e .. It created the .egg-info directory so that it exists when you run
pserve from the container. The virtualenv could probably be deleted at that point.
I’m really not sure it’s the best solution, but at least, now you know the cause of the problem.