Should I Pin Dev Requirements As Well, Or Just The Installation Requirements?

I'm thinking that I should only pin installation requirements, like I did here for example:

pinned:https://github.com/Laurentiu-Andronache/nano-python/blob/master/requirements.pip

unpinned, because they're dev requirements:https://github.com/Laurentiu-Andronache/nano-python/blob/master/requirements-dev.pip

The advantage would be that for users installing the app, it works out of the gate. And devs will be able to take advantage of dev tool improvements (better git hooks pre-commit auto-update, pytest updates pip install --upgrade -r requirements-dev.pip etc. in order to potentially solve more issues)

I think the right answer here is that there should be two files, one with permissive requirements and one with a pinned, tested set of packages. It's not realizable in a good and easy way right now, since most python projects get distributed with a single requirements.txt (or as in your case, requirements.pip) file, but some time in the future pipfile will probably become the new standard.

So in short, I think your current approach is ok and doesn't need to be fixed or anything, but an optimal solution would include one reqirements-file that looks like this and is maintained by hand:

certifi
chardet
idna>=2.3

and one lockfile that looks like this that is created by some tool (for example pip freeze) after a successful deployment:

certifi==2019.3.9
chardet==3.0.4
idna==2.6

If you think that would make sense for your project, feel free to become an early adopter of an established lockfile format (through a tool like pipenv or poetry), which is a lot better than raw textfiles.

To answer the question about distinguishing between dev and non-dev packages, the pipfile format includes them in the same file and different sections, and has them all unpinned in the pipfile and pinned in the lockfile. That seems to be the approach by the guys in charge of python packaging who wrote the pipfile code, so I'd just go ahead and trust their judgement.