Fix for fields using db_column - #139
Conversation
There was a problem hiding this comment.
I can move these to a different PR, but I found it helpful to locally test the different Django versions. Tox also supports UV, so if you'd prefer using that then that plugin could be added, but I'm not sure if it's necessary unless the CI starts using tox (in that case tox-gh might make sense too)
There was a problem hiding this comment.
I think this is fine for now, although I have not used tox, so wonder if I will find it difficult to maintain?
The tests workflow on Github Actions dynamically builds its matrix from the classifiers list in this file. Would it be possible to do that with tox so the list of versions doesn't need to be maintained in multiple places?
There was a problem hiding this comment.
Unfortunately I don't believe so unless you write a tox plugin. I did notice that generation, but I wasn't sure if that's mainly because it's in a different file and it's less likely you'll notice that two files need to change. The dynamic build isn't completely dynamic since you do have to maintain the exclusion list, but I understood what you were going for.
Tox is pretty useful, but really just being able to easily run the tests locally is pretty important when trying to verify you're not breaking things across Python/Django versions. As far as maintenance this would just be reading the Django release notes and figuring out which released versions support which Python version ranges and adding a new env_list item for each supported release and then translating the Django factor into a version range (it would be nice if that could be automatic, but it's not too hard to add)
db_column
bcbe4e5 to
1a5785a
Compare
fixes: #95