5 ms·

> That is impossible, it will never happen. Packages will have different maintenance cycles, some will get deprecated, others abandoned... You can't base your u

> That is impossible, it will never happen. Packages will have different maintenance cycles, some will get deprecated, others abandoned... You can't base your upgrade policy on an impossible situation. You realize that if that was "impossible" and "never happening", then absolutely no Python environment would be working ever? > A version conflict should be reported as an installation failure, not allow you to continue. Please don't make this mandatory. > Pip will install Y >= 2.0 and won't care that package X is now broken. Fine, I'll just quickly fix X and open a pull request, like I probably did a hundred times, then eventually if necessary deploy my fork with the fix meanwhile they do their maintenance release. Should we not take the responsibility of the dependencies we use and contribute back?? > The "live at master" philosophy only works for small groups of similar output capacity. It won't work for an ecosystem as wide as Python. I don't understand why, but I'm talking about "live at latest release", not "at master". > Sometimes it will be necessary, such as for example a package dropping support for a feature that another one needs. Then the package can just paste the code of the feature in their own, until a new lib does it, I remember having to do that twice in 20 years (except I didn't just "paste" it, but implemented a much smaller version). Overall, it seems my approach produces versions of my software and software that I depend on that are compatible with all versions because you can always use an earlier version if you really want to deploy on an old python or whatnot, whereas you approach leads to broken packages, tech debt, and blaming the package manager.

gjulianm 5y ago
> You realize that if that was "impossible" and "never happening", then absolutely no Python environment would be working ever? No, it means that you can't be fully sure that upgrading everything to the latest version is not going to break anything. And right now, you can't. You can only do that in controlled environments (say, a distro's official package repositories), not with Python packages. > Please don't make this mandatory. It is mandatory in quite a lot of package managers. APT, for example, will refuse to install packages with conflicting versions or breaking things. It's better to fail early with a clear message than to have a later failure where the cause is unclear. > Fine, I'll just quickly fix X and open a pull request, like I probably did a hundred times, then eventually if necessary deploy my fork with the fix meanwhile they do their maintenance release. That's optimistic. What about detecting which package is causing the issue? What if the fix is not quick? What if the package developers are working on compatibility but it's going to take time? > I don't understand why, but I'm talking about "live at latest release", not "at master". Problem is similar. You can't live at latest release with software coming from wildly different developers, with wildly different policies on compatibility, versioning, breaking changes, bugs... > Then the package can just paste the code of the feature in their own, until a new lib does it, I remember having to do that twice in 20 years (except I didn't just "paste" it, but implemented a much smaller version). Again, pretty optimistic. You won't be able to do that with all packages. For example, right now I have a project that needs to work on Python 3.6 (among other packages). Latest numpy versions dropped support for Python 3.6, so the project needs to restrict numpy versions to maintain compatibility. I can't just take the latest numpy and patch it for Python 3.6. > Overall, it seems my approach produces versions of my software and software that I depend on that are compatible with all versions because you can always use an earlier version if you really want to deploy on an old python or whatnot, whereas you approach leads to broken packages, tech debt, and blaming the package manager. You also spend time doing maintenance and debugging on new installations to debug and fix compatibility issues, when those upgrades might not bring any value to the product. In my case, I do that debugging and fixing in a controlled environment, only when I decide to upgrade the packages, and maybe revert/pin the ones that don't have quick fixes. That's the difference. Once a given package is released/packaged for distribution, I want dependencies to be fixed so that every new installation works, and doesn't fail if some developer decided to break things that day.
- 1337shadow 5y ago
  > you can't be fully sure that upgrading everything to the latest version is not going to break anything. Well, it's still what you do every time you create a new project. > It is mandatory in quite a lot of package managers. Ok but many packages won't be installable at all anymore, because people pin different versions instead of maintaining their packages by continuously integrating upstream releases. > You can't live at latest release with software coming from wildly different developers, with wildly different policies on compatibility, versioning, breaking changes, bugs... Well I didn't know can't so I did. > I can't just take the latest numpy and patch it for Python 3.6. Instead, you should be upgrading your code to support the newer numpy version. Seriously, try it out, you'll be spending less effort at the end of the year. > You also spend time doing maintenance and debugging on new installations to debug and fix compatibility issues, when those upgrades might not bring any value to the product. I spend less time and more spread over the year, bringing value to the whole ecosystem of packages which are bringing value to my product, and bringing value to myself as I develop new products with the dependencies I like and support as such. > In my case, I do that debugging and fixing in a controlled environment I wait for CI or users to report that a new release isn't compatible so I can fix it as soon as possible, in which case we temporarily pin versions, instead of piling up tech debt until it's so huge the whole project becomes trash. That's what I call taking responsibility with the dependencies that you include in your product.
  - gjulianm 5y ago
    > Well, it's still what you do every time you create a new project. Yep, and it is a pain in the ass when the package you want to use creates a dependency conflict. Luckily, at that stage I can still search for an alternative with little to no cost. > Ok but many packages won't be installable at all anymore, because people pin different versions instead of maintaining their packages by continuously integrating upstream releases. And some packages won't be installable anymore because they use deprecated APIs, or were only compatible with Python 2, or expected certain files/folders/programs to be present on the system and they aren't anymore. Packages go into abandonware all the time, removing version pinning doesn't fix that. > Instead, you should be upgrading your code to support the newer numpy version. Seriously, try it out, you'll be spending less effort at the end of the year. Thank you for telling me this, I will be relaying to my clients that they need to upgrade their systems to newer Python versions to get new features, surely that will go well. > I wait for CI or users to report that a new release isn't compatible so I can fix it as soon as possible, in which case we temporarily pin versions, instead of piling up tech debt until it's so huge the whole project becomes trash. Well, I prefer to not have my program crashing in client environments because someone decided to update a package and break things. > piling up tech debt until it's so huge the whole project becomes trash. Waiting to release on new dependency versions until those versions are tested is not tech debt. I mean, semantic versioning was done with this purpose precisely: to signal which upgrades are just bug fixes and you should upgrade ASAP, which ones are new features so you can upgrade without too many problems, and which upgrades break compatibility and you should test it thoroughly in case something broke. If living at latest release works for you and dealing with dependency issues on new installations is not a problem, then go. But other systems will require that a certain release installs dependencies on a consistent manner. Some of my dependencies are automatically upgraded and tested before release, others are pinned because they always break things and I only upgrade manually. But once a version of a package is released, that one goes with version pinning because I prefer to avoid the risk of a client installing the software and having to explain them than "oh, it's just that this dependency released a new version that broke things and we didn't specify the version that our software needed".

gjulianm 5y ago

> You realize that if that was "impossible" and "never happening", then absolutely no Python environment would be working ever? No, it means that you can't be fully sure that upgrading everything to the latest version is not going to break anything. And right now, you can't. You can only do that in controlled environments (say, a distro's official package repositories), not with Python packages. > Please don't make this mandatory. It is mandatory in quite a lot of package managers. APT, for example, will refuse to install packages with conflicting versions or breaking things. It's better to fail early with a clear message than to have a later failure where the cause is unclear. > Fine, I'll just quickly fix X and open a pull request, like I probably did a hundred times, then eventually if necessary deploy my fork with the fix meanwhile they do their maintenance release. That's optimistic. What about detecting which package is causing the issue? What if the fix is not quick? What if the package developers are working on compatibility but it's going to take time? > I don't understand why, but I'm talking about "live at latest release", not "at master". Problem is similar. You can't live at latest release with software coming from wildly different developers, with wildly different policies on compatibility, versioning, breaking changes, bugs... > Then the package can just paste the code of the feature in their own, until a new lib does it, I remember having to do that twice in 20 years (except I didn't just "paste" it, but implemented a much smaller version). Again, pretty optimistic. You won't be able to do that with all packages. For example, right now I have a project that needs to work on Python 3.6 (among other packages). Latest numpy versions dropped support for Python 3.6, so the project needs to restrict numpy versions to maintain compatibility. I can't just take the latest numpy and patch it for Python 3.6. > Overall, it seems my approach produces versions of my software and software that I depend on that are compatible with all versions because you can always use an earlier version if you really want to deploy on an old python or whatnot, whereas you approach leads to broken packages, tech debt, and blaming the package manager. You also spend time doing maintenance and debugging on new installations to debug and fix compatibility issues, when those upgrades might not bring any value to the product. In my case, I do that debugging and fixing in a controlled environment, only when I decide to upgrade the packages, and maybe revert/pin the ones that don't have quick fixes. That's the difference. Once a given package is released/packaged for distribution, I want dependencies to be fixed so that every new installation works, and doesn't fail if some developer decided to break things that day.

1337shadow 5y ago
> you can't be fully sure that upgrading everything to the latest version is not going to break anything. Well, it's still what you do every time you create a new project. > It is mandatory in quite a lot of package managers. Ok but many packages won't be installable at all anymore, because people pin different versions instead of maintaining their packages by continuously integrating upstream releases. > You can't live at latest release with software coming from wildly different developers, with wildly different policies on compatibility, versioning, breaking changes, bugs... Well I didn't know can't so I did. > I can't just take the latest numpy and patch it for Python 3.6. Instead, you should be upgrading your code to support the newer numpy version. Seriously, try it out, you'll be spending less effort at the end of the year. > You also spend time doing maintenance and debugging on new installations to debug and fix compatibility issues, when those upgrades might not bring any value to the product. I spend less time and more spread over the year, bringing value to the whole ecosystem of packages which are bringing value to my product, and bringing value to myself as I develop new products with the dependencies I like and support as such. > In my case, I do that debugging and fixing in a controlled environment I wait for CI or users to report that a new release isn't compatible so I can fix it as soon as possible, in which case we temporarily pin versions, instead of piling up tech debt until it's so huge the whole project becomes trash. That's what I call taking responsibility with the dependencies that you include in your product.
- gjulianm 5y ago
  > Well, it's still what you do every time you create a new project. Yep, and it is a pain in the ass when the package you want to use creates a dependency conflict. Luckily, at that stage I can still search for an alternative with little to no cost. > Ok but many packages won't be installable at all anymore, because people pin different versions instead of maintaining their packages by continuously integrating upstream releases. And some packages won't be installable anymore because they use deprecated APIs, or were only compatible with Python 2, or expected certain files/folders/programs to be present on the system and they aren't anymore. Packages go into abandonware all the time, removing version pinning doesn't fix that. > Instead, you should be upgrading your code to support the newer numpy version. Seriously, try it out, you'll be spending less effort at the end of the year. Thank you for telling me this, I will be relaying to my clients that they need to upgrade their systems to newer Python versions to get new features, surely that will go well. > I wait for CI or users to report that a new release isn't compatible so I can fix it as soon as possible, in which case we temporarily pin versions, instead of piling up tech debt until it's so huge the whole project becomes trash. Well, I prefer to not have my program crashing in client environments because someone decided to update a package and break things. > piling up tech debt until it's so huge the whole project becomes trash. Waiting to release on new dependency versions until those versions are tested is not tech debt. I mean, semantic versioning was done with this purpose precisely: to signal which upgrades are just bug fixes and you should upgrade ASAP, which ones are new features so you can upgrade without too many problems, and which upgrades break compatibility and you should test it thoroughly in case something broke. If living at latest release works for you and dealing with dependency issues on new installations is not a problem, then go. But other systems will require that a certain release installs dependencies on a consistent manner. Some of my dependencies are automatically upgraded and tested before release, others are pinned because they always break things and I only upgrade manually. But once a version of a package is released, that one goes with version pinning because I prefer to avoid the risk of a client installing the software and having to explain them than "oh, it's just that this dependency released a new version that broke things and we didn't specify the version that our software needed".