search

python-discord / django-crispy-bulma

Django application to add 'django-crispy-forms' layout objects for Bulma.io
MIT License
25 stars 9 forks source link

Require only a minimum django-crispy-forms version #27

Closed ckrybus closed 5 years ago

ckrybus commented 5 years ago

django-crispy-forms is a library, the requirements shoudn't be so strict.

sco1 commented 5 years ago

Hello! This would be best started as a discussion in the issue we have open for updating the dependencies (#25), or even the PR we have open for updating the dependencies (#26).

Thanks!

ckrybus commented 5 years ago

Hi, thanks, I saw them, but they were for development/extra packages. My change was for a primary dependency.

The problem is this: if every library had hard-pinned dependencies nobody would be able to install anything because of package conflicts during install.

I might be wrong, but to my knowledge it is best practice to hard-pin project dependencies, but soft-pin library dependencies (I consider django-crispy-bulma to be a library).

It's basically a tradeoff, too rigid is bad, too open is also bad. I proposed:

django-crispy-forms>=1.7.2

but you could modify it so:

django-crispy-forms>=1.7.2,<2.0

This would make it more flexible and only slightly less "secure", because django-crispy-forms seems to follow semver versioning.

Just my two cents. Right now I'm using my custom fork, because I want to use the newest django-cirspy-forms and the newest django-crispy-bulma.

sco1 commented 5 years ago

This would make it more flexible and only slightly less "secure", because django-crispy-forms seems to follow semver versioning.

We can't rely on "seems to." We are not opposed to making adjustments to the dependency pinning, but would like to have a discussion about it first rather than cold-PRing something with an unkown effect on the maintenance burden of our package.

MarkKoz commented 5 years ago

FWIW I do find it odd that it's being pinned to a patch version. I would have thought ~=1.7.2 is at least fine. Granted, there are exceptions to this - depends on the versioning scheme of the library.

If we were to evaluate that this dependency does not have breaking changes in minor versions (i.e. does follow semver), then doing >=1.7.2,<2 would be fine. Otherwise, we would have to periodically manually check the latest minor release and bump the pinned version.