Django settings modules not found? ModuleNotFoundError

Hi, at my first contact with CI I run into troubles while setting up an test coverage analysis. My local test runs fine within it’s virtualenv:
coverage run manage.py test --settings papersquirrel.settings.ci .

But when I setup travis, I get an error:

ModuleNotFoundError: No module named ‘papersquirrel.settings.ci’

I tried various options and constellations, but it seems that I didn’t understand some aspects of the python path :frowning_face:

My project looks like:

├── manage.py
├── papersquirrel
│   ├── __init__.py
│   ├── __pycache__
│   ├── settings
│   │   ├── base.py
│   │   ├── ci.py
│   │   ├── example.py
│   │   ├── __init__.py
│   │   └── __pycache__
│   ├── urls.py
│   └── wsgi.py
├── readme.md
├── requirements.txt
├── res
├── squirrel
│   ├── admin.py
│   ├── apps.py
│   ├── forms.py
│   ├── __init__.py
│   ├── management
│   │   └── commands
│   ├── migrations
│   │   ├── __init__.py
│   │   └── __pycache__
│   ├── models.py
│   ├── __pycache__
│   ├── templates
│   │   └── squirrel
│   ├── tests
│   │   └── basic-html.html
│   ├── tests.py
│   ├── urls.py
│   ├── utils.py
│   └── views.py
├── static 

My .travis.yml is like this:

...
env:
  -DJANGO=2.2 DB=sqlite3
  - DJANGO_SETTINGS_MODULE='papersquirrel.settings.ci'

# install requirements
install:
  - pip install -r requirements.txt
  - pip install coveralls

# To run tests
script:
  - coverage run --source=./ manage.py test --settings=papersquirrel.settings.ci
...

Can anybody with more env experience pls. point me to my misunderstanding?

My guess is: you need to add the current directory to Python path:

- export PYTHONPATH="$(pwd)"
- coverage <etc>

As per

you are running manage.py through coverage – a wrapper over a Python script. So the directory where that wrapper is located is added to sys.path instead of the current directory.

Unfortunatly, this doesn’t seem to solve my problem :slightly_frowning_face:
I added

before_install:
  - export PYTHONPATH=$PYTHONPATH:$(pwd) 

and checked the variable via echo. It looks good and includes the directory of my project. Also just invoking python manage.py test results in this issue …

I also tried to rollout the repo on another server to avoid bugs due local artifacts, but also on that server everything works fine.
Sorry, but any further ideas?

Well, debugging is the further idea. It’s always the same:

  • Identify the exact place in the code where the error manifests itself
  • Examine the program’s state at that moment to find out which of the values is wrong
  • Track the wrong value back to its origin

You can insert debug printing into files if you know how to do that on the fly, or request debug mode for your project and edit the code by hand or run it under debugger.

Well, 40+ builds later and trying different ideas, but I didn’t solved the problem yet and I’m close to give up :sob:

First I just try to run only the testsuites itself, but n
All in all, this seems to be a problem with the import path, but I checked, that the project root folder and the settings subfolder are on the paths:

$ echo $PATH

/home/travis/virtualenv/python3.6.7/bin:/home/travis/bin:/home/travis/.local/bin:/usr/local/lib/jvm/openjdk11/bin:/opt/pyenv/shims:/home/travis/.phpenv/shims:/home/travis/perl5/perlbrew/bin:/home/travis/.nvm/versions/node/v8.12.0/bin:/home/travis/.rvm/gems/ruby-2.5.3/bin:/home/travis/.rvm/gems/ruby-2.5.3@global/bin:/home/travis/.rvm/rubies/ruby-2.5.3/bin:/home/travis/gopath/bin:/home/travis/.gimme/versions/go1.11.1.linux.amd64/bin:/usr/local/maven-3.6.0/bin:/usr/local/cmake-3.12.4/bin:/usr/local/clang-7.0.0/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/snap/bin:/home/travis/.rvm/bin:/home/travis/.phpenv/bin:/opt/pyenv/bin:/home/travis/.yarn/bin:/home/travis/build/Matthias84/papersquirrel:/home/travis/virtualenv/python3.6.7/bin:/home/travis/bin:/home/travis/.local/bin:/usr/local/lib/jvm/openjdk11/bin:/opt/pyenv/shims:/home/travis/.phpenv/shims:/home/travis/perl5/perlbrew/bin:/home/travis/.nvm/versions/node/v8.12.0/bin:/home/travis/.rvm/gems/ruby-2.5.3/bin:/home/travis/.rvm/gems/ruby-2.5.3@global/bin:/home/travis/.rvm/rubies/ruby-2.5.3/bin:/home/travis/gopath/bin:/home/travis/.gimme/versions/go1.11.1.linux.amd64/bin:/usr/local/maven-3.6.0/bin:/usr/local/cmake-3.12.4/bin:/usr/local/clang-7.0.0/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/snap/bin:/home/travis/.rvm/bin:/home/travis/.phpenv/bin:/opt/pyenv/bin:/home/travis/.yarn/bin:/home/travis/build/Matthias84/papersquirrel:/home/travis/build/Matthias84/papersquirrel/papersquirrel/settings 

python -c 'import sys; print(sys.path)'

['', '/home/travis/build/Matthias84/papersquirrel', '/home/travis/build/Matthias84/papersquirrel/papersquirrel/settings', '/home/travis/virtualenv/python3.6.7/lib/python36.zip', '/home/travis/virtualenv/python3.6.7/lib/python3.6', '/home/travis/virtualenv/python3.6.7/lib/python3.6/lib-dynload', '/opt/python/3.6.7/lib/python3.6', '/home/travis/virtualenv/python3.6.7/lib/python3.6/site-packages']

If I skip the --settingsparameter, the suite runs as expected, but of course it doesn’t has the right settings to do it’s job.
I also tried different other approaches, that say it’s a problem of the travis virtualenv or to find my module itself:

  • switch to python3
  • invoke via python -m
  • create init.py at root folder
  • try only settings.ci instead
  • rename project folder to uniqe name

Any help would be appreciated :confused:

A check of file structure and sys.path at the time of import shows…

… that the 2nd check was unnecessary. There’s no ./papersquirrel/settings/ci.py. Apparently, you forgot to commit it…


Update: the link above is now dead. This is what I did there, roughly:

script:
  - |-
    python -m pdb <path-to-coverage> <args> <<!
    b <faulty_file:faulty_line_that_does_the_import>
    c
    import sys,os
    os.system("ls -Rl")
    p sys.path
    c
    q
    !
1 Like

God damnit, you are right! :superhero: My .gitignore blocked the settings file and my test on another server was with a custom local settings file …
Sometimes it’s the most basic things … thank you very much!