Please if I may know, is everything in nose written and taking note of how we make the directories and modules in the project skeleton? I mean how we structured the project skeleton directories, is that a standard way for nose in particular?
It’s not Nose specific, just typical of a general structure.
The key is to be mindful that Python requires a dunderinit (ie __init__.py) file in each ‘folder’ to indicate that they are a package. This lets you handle a folder or files/modules much easier when importing (nice explanation here: https://timothybramlett.com/How_to_create_a_Python_Package_with___init__py.html
Nose seems to be very sensitive to this, and this section of the book gets so many comments about failure to find tests.
Most people drop Nose for PyTest or stick with Unittests.
1 Like
Thank you. If I may ask, do I need different venvs (directories) for different projects?
It’s personal choice really. The idea behind virtualenv is that is suitable small so you can isolate your python modules/libraries specifically for that project. This creates a nice partition so you only need a small set of project dependencies and can keep your configuration nice and tidy.
But given that you might be using a fairly simple set up without lots of libraries, you might find that you want some standard environments for general use, that are located somewhere more centralised. I think Zed creates a hidden .venv directory at root in the book so I have a similar set up for different python versions; 3.5, 3.6, 3.7, 3.8 … so I can run any project against them if I want to.
The only problem with these environments is that they tend to be full of lots of library installs with latest versions, not the project specific versions that can be managed within the project environment (using a requirements.txt file).
1 Like