I have rules for this after about a billion years of experiencing it.
1. minimize dependencies - batteries included is best unless it will take forever to write, keeping a local copy (like Linus' idea of static linking) is next best
-- a certain amount of reinventing the wheel is tolerable if you are optimizing for mimimal rot.
1a. ORMs and testing packages rot because what is popular today becomes unsupported when the next flavor of the month comes along. Ask yourself whether select Customer, ID from Invoices really needs that layer of abstraction. Ask yourself if that test is really so complex it needs a framework.
2. Mocks sounds great until you have a rush feature or incident to manage, and get busy. Use integration tests for things that would need mocking. Insist on green across the board or it doesn't ship as a cultural value.
2. use neutral (https REST) APIs to segregate logical components. The analogue of this in single-binary programs are pimpl idiom type things, depending on the language. This acts as a firebreak so you can replace code behind an API without the consumers caring.
3. version all apis and all data. Further provides firebreaks and lets you manage users by degrading QOS for older versions till they upgrade.
"Python’s pip don’t support having multiple versions of a given package installed at the same time, which could mean that the version of a package you request could clash with other software already installed on a given system."
> I am confused... how does the builtin venv (virtual environment) not solve this particular problem?
1. minimize dependencies - batteries included is best unless it will take forever to write, keeping a local copy (like Linus' idea of static linking) is next best -- a certain amount of reinventing the wheel is tolerable if you are optimizing for mimimal rot.
1a. ORMs and testing packages rot because what is popular today becomes unsupported when the next flavor of the month comes along. Ask yourself whether select Customer, ID from Invoices really needs that layer of abstraction. Ask yourself if that test is really so complex it needs a framework.
2. Mocks sounds great until you have a rush feature or incident to manage, and get busy. Use integration tests for things that would need mocking. Insist on green across the board or it doesn't ship as a cultural value.
2. use neutral (https REST) APIs to segregate logical components. The analogue of this in single-binary programs are pimpl idiom type things, depending on the language. This acts as a firebreak so you can replace code behind an API without the consumers caring.
3. version all apis and all data. Further provides firebreaks and lets you manage users by degrading QOS for older versions till they upgrade.