Poetry, Black and pytest?

[denizdogan]

Poetry, Black and pytest?

[mitar]

I want to be clear that at this point, I'm not trying to convince you about changing django-missing one way or another, I'm just interested in the discussion it's evolved into. :)

Same. :-)

I think it's misguided to expect developers who are interested in contributing to django-missing to install Docker

Sure. A fair point. For me this is why there is a cloud service. I do not mind people just pushing and leaving to CI to run everything. In a way, you just use it as a cloud service so you do not have to run tests locally. This is even simpler than running it locally.

But yes, this is really about me being used to Docker so it is simply easier to use same approach to testing for all apps and libraries.

[mitar]

Use Poetry for dependency/package management?

I do not think this package has any/many dependencies, so not sure if we need anything more than setuptools? But I have not yet used Poetry myself (but do know about it), so feel free to explain where you see the benefits?

Use Black for formatting?

I do generally like this, so feel free to make a PR which goes over the whole package and reformats (and only reformats, no other changes to code). You can also add it to CI to make sure things are kept in check (so not to commit automatically, but to check if there would be any formatting change).

The only code style difference I do not like there is that I like keeping user-facing strings inside "..." and constants inside '...'. So please use it with --skip-string-normalization.

Also, for imports, I would want that we import always just modules, never symbols directly.

Use pytest and tox for the unit tests?

I do not find them useful enough to go away from the standard libraries. Care to explain what do you see them bringing to this particular project?

Use Hypothesis for test data?

I have not know about this project before. From quick look I do not think code here would benefit from it too much. Code in this project are generally a lot of small hacks which hook into Django internals. So writing tests really requires anticipating how Django works or could not work. Not sure if we have code examples which would fail on unknown data? Maybe explain a bit more here as well.

[denizdogan]

Thanks for the quick response!

Poetry

1. Intuitive CLI for managing dependencies, building, publishing, etc.
2. Keeps a lockfile of the dependencies for safety

As you say, there are currently no dependencies, which I generally like, but for development I'd love to be able to use Hypothesis, pytest and tox. And then of course Black for the formatting. And pre-commit for making sure the code is fine before committing. And then isort for the import style. And then seed-isort-config for automatically updating the known_third_party configuration for isort. 😉

I'm not that familiar with setuptools and I don't know how to add test dependencies to it and how to install them into my virtualenv. With Poetry this is a no-brainer.

pytest/tox

I love writing unit tests with pytest because it's just so simple. You don't have to use classes for anything (less indentation, no inheritance) and you can inject "fixtures" very easily by just adding the name of the fixture as an argument for the test function.

Honestly, I don't know how to run the current test suite from PyCharm, so I had to use the terminal for running them, so it's partly that as well. pytest is also easier to integrate with Hypothesis for tests involving Django in my experience.

With tox we could make sure the library is compatible with various Python versions instead of just targeting Python 3.6 like we do today, each being tested in their own temporary virtualenv.

Hypothesis

Hypothesis is great for making sure you're really covering all bases. A lot of times it will find strange edge cases which a normal mortal human like me couldn't think up. Sometimes it will also make your code shorter and more readable. For an example, take a look at TestTrailing from my project django-whiteless: https://github.com/denizdogan/django-whiteless/blob/master/tests/test_whiteless.py#L157

[mitar]

I thought a bit about this and it feels to me it is really just a matter of taste. I am not yet sure if it matters a lot. It probably depends on the question of how much you are interested in contributing to this package. If you would like to take over maintainership, then probably changing things so that it is the easiest for you would be the best. But until then I think I prefer things which I am used to and make sense to me. For example, unittests are simply discovered automatically by PyCharm for me. It just works. But yes, like anything, one has to figure things a bit.

BTW, I just noticed that this package was licensed under AGPL and I changed it to BSD, I think is better for such utility functions.

I don't know how to add test dependencies

This is why I like unittest, there are no test dependencies then. :-)

I love writing unit tests with pytest because it's just so simple. You don't have to use classes for anything (less indentation, no inheritance

Ha ha. I am the opposite here. I love test classes and structuring them, and having assert methods on the instance.

With tox we could make sure the library is compatible with various Python versions instead of just targeting Python 3.6 like we do today

This is not really true. Instead of using tox to do this, this package uses Travis CI to do this and defines test matrix here:

https://github.com/wlanslovenija/django-missing/blob/master/.travis.yml

Hypothesis

It seems it works with unittests as well.

[denizdogan]

That's all fair, I just wanted to throw up the possibility :) That being said, Travis CI is good and all, but I can't run Travis CI locally, whereas with tox I can test against any Python version I like without pushing any code from my computer, so that's a pretty big deal in my opinion :)

[mitar]

That being said, Travis CI is good and all, but I can't run Travis CI locally,

You can, using travis-build and Docker.

Maybe I am biased because many my projects have also often non-Python dependencies, so Docker is then great to capture those.

[denizdogan]

You're absolutely right, I can use Docker for that. Maybe this is just another matter of personal preference and opinion, but I try to avoid using Docker (and VMs in general) if I don't really need them. I do use Docker for other projects, but incorporating such heavy machinery for something as simple as running unit tests which never even make a database connection seems excessive to me.

tox is a tool which does the job just fine with almost no configuration. Installing Docker to just be able to run a simple test suite properly looks misguided to me. You just said that you prefer unittest because then there are no dependencies, but you're completely open to using Travis in a Docker container to execute them? :)

[mitar]

But you do not use tox to deploy. If I use Docker, I can use it both for testing and deploying. I do not have to worry about slight potential differences. I am probably just buying into this idea of Docker making sure that deployment is the same as my development environment.

You just said that you prefer unittest because then there are no dependencies, but you're completely open to using Travis in a Docker container to execute them? :)

He he. :-) Yes, because Docker for me is not just for testing, but also for deployment. :-)

[denizdogan]

I want to be clear that at this point, I'm not trying to convince you about changing django-missing one way or another, I'm just interested in the discussion it's evolved into. :)

For applications which are intended for deployment on some remote environment, I will use Docker/K8S myself, I don't have any problem with that. But this is not an application, this is a library which will be published to PyPI and then installed as a third-party dependency by applications or other libraries. I think it's misguided to expect developers who are interested in contributing to django-missing to install Docker and run the unit tests via Travis CI for several reasons:

1. It's resource heavy
2. It requires some understanding of Docker
3. It's not always easy to install

EDIT: I accidentally pressed Cmd+Enter before I was done but I'll just leave the comment as it is :D