Should the PVP be changed with regards to instances?
spam at scientician.net
Wed Dec 21 19:10:56 CET 2011
Jeremy Shaw wrote:
> On Wed, Dec 21, 2011 at 11:24 AM, wren ng thornton <wren at freegeek.org>
>> Agreed with this. And with Ganesh Sittampalam: the solution to the
>> problem of major version changes is automated testing/reporting, not
>> allowing potentially breaking changes in minor versions.
> Let's say the authors of text add a new instance. I can not
> actually update to that new version of text until all the other
> libraries I use that depend on it are updated. For a very popular
> library, like text, than can take awhile. So, I am stuck with the old
> version until everybody updates -- and probably all they are going to
> do is bump the version range.
One of the major problems here, I find, is the fact that packages that your
package depends on *but which are not part of the API to your package
exposes to the world* lead to conflicts. (I this solvable currently? Perhaps
one can create both an *-api package and a *-impl package?)
> Alternatively, a system where libraries exported some sort of
> declaration of the API they need, so that the PVP is irrelevant would
> be nice too -- if such a thing could be made to work. The core issue
> is, after all, that we basically have a single bit of information that
> we use to declare that the API is changed. That is obviously not very
> fine grained...
Separation of what the package API actually *is* versus what it uses
internally would be extremely desirable. I usually find that it's actually
"implementation" dependencies that get me into trouble with dependency
I realize that it may not exactly be a trivial proposition to implement
something like this, but AFAICT .cabal files actually contain enough
information to (theoretically at least) be able to implement this.
More information about the Libraries