Code Chores: The boring part of maintaining
1–10 of 13 posts
Re: Code Chores: The boring part of maintaining
#2It would have been nice to have a little more context on what the project cited is in the second paragraph.
Re: Code Chores: The boring part of maintaining
#3It would have been nice to have a little more context on what the project cited is in the second paragraph.
I definitely thought the URL was https://pola.rs/ so I was confused when he started talking about Django
Re: Code Chores: The boring part of maintaining
#4It would have been nice to have a little more context on what the project cited is in the second paragraph.
Sorry about that, I will add that info. I thought nobody outside of the project would read it TBH.
Re: Code Chores: The boring part of maintaining
#5Re: Code Chores: The boring part of maintaining
#6Sorry for the confusion if you thought this was a rust project; here is the explanation I added to the text:
InvenTree is an Open Source (MIT), self-hosted inventory and part library management system written mainly in Python. It uses Django and DRF to expose a REST API that can be used from the web, iOS and Android apps, a Python library and IOT devices.
Source code: https://github.com/inventree/inventree
Re: Code Chores: The boring part of maintaining
#7Very interesting write up. Updating things is non-trivial as often you may depend on something that will eventually decide to deprecate a feature you actually used or some library/framework will decide to completely redo their API every five to ten years and then you suddenly have to start an upgrade in your project and try to keep this transparent to your users so things doesn't change for them or you need to figure some path to deal with backwards compatibility.
There are always an assorted amount of chores the more the project ages and has active users, these tasks often end up invisible as they don't get a featured spot in the release notes.
Re: Code Chores: The boring part of maintaining
#8Very interesting write up. Updating things is non-trivial as often you may depend on something that will eventually decide to deprecate a feature you actually used or some library/framework will decide to completely redo their API every five to ten years and then you suddenly have to start an upgrade in your project and try to keep this transparent to your users so things doesn't change for them or you need to figure…
Choosing the right dependencies is a craft that needs to be learned. I find myself looking into the ppl. behind libraries more and more. I will always prefer something striped down from a known person in the space to the solution of a newcomer. Hoping between APIs every few years gets old fast.
Re: Code Chores: The boring part of maintaining
#9Very interesting write up. Updating things is non-trivial as often you may depend on something that will eventually decide to deprecate a feature you actually used or some library/framework will decide to completely redo their API every five to ten years and then you suddenly have to start an upgrade in your project and try to keep this transparent to your users so things doesn't change for them or you need to figure…
Choosing the right dependencies is a craft that needs to be learned. I find myself looking into the ppl. behind libraries more and more. I will always prefer something striped down from a known person in the space to the solution of a newcomer. Hoping between APIs every few years gets old fast.
In my mind I was specifically thinking of SDL doing the 2 to 3 transition, not really a newcomer. I also experienced this in the WebView transition from Qt4 to Qt5. I also still remember the python 2 to 3 transition in the beginning. There are definitely more cases of a very established library/framework breaking things.
Re: Code Chores: The boring part of maintaining
#10Earlier quoted context omitted.
Choosing the right dependencies is a craft that needs to be learned. I find myself looking into the ppl. behind libraries more and more. I will always prefer something striped down from a known person in the space to the solution of a newcomer. Hoping between APIs every few years gets old fast.
In my mind I was specifically thinking of SDL doing the 2 to 3 transition, not really a newcomer. I also experienced this in the WebView transition from Qt4 to Qt5. I also still remember the python 2 to 3 transition in the beginning. There are definitely more cases of a very established library/framework breaking things.
Qt updates (especially when using something like PySide additionally) are always rough. I waited long enough with Python that the tooling for the switch got good. Large breaking changes luckily seem to happen less in the python ecosystem. There is a lot of movement in the dev-tools currently but CPython seems to really focus on gradual improvements - which I appreciate a lot.