Feature request - Incompatible packages / anti-dependencies

[mrahl]

As a package author, I would like the possibility to declare the opposite of a dependency, a package that my package is not compatible with.

My scenario is I maintain a package with a large installed base, let's call this package Core. I then create experimental features and release them in separate packages depending on Core (usually they're some extension to functionality in Core), call them Experimental1, Experimental2...

Some package, say Experimental2, proves to be very popular and working well. But many of my users don't get the new feature because they just update Core. So I decide to move the feature from Experimental2 to Core. To try to avoid duplication in the feature I can then release an "empty" version of Experimental2 and update its dependency to a version of Core that contains the feature instead.

BUT what I cannot do is to prevent someone from using an older version of Experimental2 with a newer version of Core, leaving them with a potentially broken installation.. IF I could declare the new version of Core as incompatible with Experimental2, this wouldn't happen.

Core having a inverse version requirement on Experimental2 would be another way (e.g. Core 2.0 would declare that Experimental2 has to be at least of version 2.0 (the emptied package) if it should be allowed to be used).

[nkolev92]

Hey @mrahl

Thanks for the detailed write-up.

Seems to me like you are trying to have your customers update different packages together.
It's definitely a challenging problem.

If the 2 packages in question are not compatible, then you can consider using upper boundaries.
We do not always recommend that because it can lead to a lot of pain when the packages with exact versions are once or twice removed, but it's achieve your wanted result, making all packages of a group contain the same version.

Obviously you have decided to go a different direction, because you simply don't know that the packages will be incompatible until a later point, but as you are likely aware, it does conflict fundamentally with the dependency approach (hence your name), so I just fear it might create something difficult to reason about.

The problem of correlating packages is definitely not a new one, we do have some issues that follow a similar line of thinking in #3114.

At this point, we can't commit getting to this, but we want to leave it open for community feedback.

[mrahl]

@nkolev92 thanks for your response. You are right that we can use upper boundaries on dependencies, and we do. But that is for major versions only. A situation like this would mean we have to bump the major version of Core just to "kill" Experimental2, while at the same time providing versions of all other ExperimentalX that are compatible with the new Core major. And we want to release new majors of Core as seldom as possible considering the implications for anyone using the package, a significantly larger group than the ones using any of the Experimentals.

Alternatively, we have to give all ExperimentalX packages very tight dependency ranges (e.g. just one or a few minors) on Core, so that we often get the opportunity to kill an Experimental. But that also means continuously publishing new versions of all Experimentals that should continue to live, to keep them compatible with newer versions of Core. This can be automated to a very high degree, but it is still a bit clumsy. And it doesn't work for all the already released Experimentals which only have the next major as upper bound... Then at least one major version release of Core is required to enter this new regime of tighter dependency intervals.

[madelson]

I've seen this come up a number of times when you want to "refactor" a package in a significant way, for example:

• We have a widely-used internal package "Monolith" which has many dependencies. We want to break up this package into smaller, more granular packages with minimal impact on existing consumers.
• To achieve this, we created a number of smaller packages "MicroPackage1", "MicroPackage2", .. "MicroPackageN" containing the various types that used to live in Monolith. We also added type forwards to Monolith.dll so that other packages that reference Monolith still work when installed in an app using the latest Monolith.

Where this breaks down is if an app using an old version of Monolith installs a package which takes MicroPackage1 as a dependency. The problem is that the latest Monolith depends on MicroPackage1, but there is no way for MicroPackage1 to communicate that it is not compatible with older versions of Monolith.