devilry / devilry-django

Devilry project main repository
http://devilry.org
BSD 3-Clause "New" or "Revised" License
51 stars 24 forks source link

Requirements clean-up #1299

Closed torgeirl closed 4 months ago

torgeirl commented 5 months ago

When installing Devilry via PIP for production, quite a few of its dependencies seems to only be relevant for development or no longer needed at all.

REMOVE

MAKE DEV ONLY

espenak commented 4 months ago

I have cleaned up dependencies in cradmin-legacy (relasing it soon). I no longer pulls in pytz, tox, sphinx, solr-thumnail and Pillow by default.

Levijatan commented 4 months ago

I have gone through the dependencies and there where a few that was not used. Using deptry I have found:

Removed the ones that are not used. Removed python-dateutil, idna, django_cradmin and six since their requirements are equivalent or stronger in other dependencies. Kept urlib3 since our has a slightly higher lowest version requirement, probably not necessary. Created 2 new optional dependencies categories one for docs and one for the internal production setup. Is the internal production setup even used?

Moved openpyxl, htmls, dj-database-url to dev, dj-static to prod. Added doc2dash, Fabric3, sphinx, and sphinx_rtd_theme to docs.

Added a small fix to comply with "newer"(>=18) pycontry to allow it to not have as rigid version requirement

Removed version requirements for xlsxwriter, it seems to be working perfect.

Removed detektor

Could not move ievv_opensource since it is used in for some batch operations and for some registry singletons. The registry singletons should be realy easy to decouple from ievv_opensource. But for the batch operations I am not so sure.

Relaxed html2text requirements, since it is only used in one place and i could not find anything breaking in its release notes.

commited the updated pyproject.toml inn 6c3d141

espenak commented 4 months ago

Moving this to 6.3 milestone and cherry-picking it into master to avoid problems/conflicts with #1290.

espenak commented 4 months ago

I do not think we should remove dj_database_url. It is a well maintained 12factor library that leads to cleaner prod configuration through environment/secret stores etc. It makes it easy to adjust database connection settings via one single URL etc.

espenak commented 4 months ago

I do not think we should remove dj_database_url. It is a well maintained 12factor library that leads to cleaner prod configuration through environment/secret stores etc. It makes it easy to adjust database connection settings via one single URL etc.

Never mind - we do not need it as a hard dependency - it can be added via requirements.txt if needed/wanted in prod.