Proposal for managing implicit/speculative version bounds #1
Conversation
| `here <https://github.com/haskell/cabal/issues/3729>`_, but it probably | ||
| requires too large a change to be practicable. | ||
|
|
||
| Other solutions involve automatically setting the required implicit constraints |
There was a problem hiding this comment.
To reframe this issue some, lets focus on what we can communicate in a .cabal file.
Currently we have no way to express:
"accept any new versions of this dependency as long as this project compiles and passes tests using them."
This is an extremely basic and important thing to be able to say. It would be worth adding special syntax to .cabal files to do so. Happily we don't have to, because we can change what "no upper bound" means in .cabal files to cover this case.
Right now "no upper bound" means:
"all futures versions of this library are valid, even if they don't compile".
This is a kind of crazy thing for someone to want to express (unless they're intentionally trying to break people's solvers) and we shouldn't help them do so. Instead we should remove this meaning of a missing upper bound, and replace it with the earlier one ("as long as this project compiles and passes tests etc.")
Obviously upper bounds will still be very important for projects that depend on the values as well as the types returned by their dependencies (and are unable to capture this in tests). But it seems to me like this would be a clear improvement to what .cabal files mean, and that since all of our infrastructure depends on .cabal files getting them right should be the our top priority.
|
|
||
| The devil is in the details with each of these strategies. We should now being | ||
| constructing concrete proposals around the alternatives, on the way to coming up | ||
| with a single solution that works for all. |
There was a problem hiding this comment.
I think the scope of this proposal should be defined better. Hackage needs a process that actually includes a feedback loop on failure.
A reason why stackage works is that it covers a lot more than what is described here.
-
What happens in failure situations?
- In stackage, someone is pinged on github. (feedback).
- On hackage, nothing?
-
What happens after multiple failures
- On stackage, it's a breakage of the maintainer's agreement.
- On hackage, nothing? In really important cases, an email to haskell-cafe (?) asking to take over a package.
Automating the bounds checking is one thing (and I love stackage), but automating and defining a minimum process, where the minimum includes:
- There must be a way to contact the maintainer.
- The maintainer must be notified when matrix.hackage.haskell.org fails.
- The maintainer must have a way to acknowledge a "ping" from the system.
- With no signs of life from a maintainer, for a failing package, the package release is marked bad in hackage somehow.
That's just a suggestion, but there MUST be a feedback loop and there must be an escalation system. Implicit or explicit. Hackage could mark packages as bad, emails can be sent, a list can be produced somewhere. This must exist, and there must be semantics associated with the feedback loop.
Stackage has this, and hackage should also have it.
There was a problem hiding this comment.
I agree that any curation process needs a well-defined human coordination part. But I think it is more complex in the hackage case than with stackage, as at any time the focus in stackage is on a single snapshot, and the entire community focuses on it. Hackage tries to get a mutually consistent set of constraints across all the packages to be able to solve for a build plan if you are forced to "pin" a particular version of a particular package for any reason.
It is sort of the difference between "there exists" and "forall".
But I personally believe hackage needs human involvement in managing the implicit/speculative constraints. And the hard part is working out what that is.
There was a problem hiding this comment.
While you are correct that no one wants buggy packages, as @alanz said, the problem is larger in scope. "Not building in the current snapshot" is a bug in stack/stackage, but not in general.
|
I highly recommend keeping each library version's dependency upper bounds outside of the .cabal file in some sort of external (to the package) metadata. The original upper bound should be in the .cabal file (as it is currently), but then any upper bound bumps should occur only in the metadata. This will allow a library to be used with later released dependencies without needing to revise the original library. All that will be necessary to allow this is to update the external metadata. I would expect this will reduce the number of minor version updates to many libraries, which will make it easier for the library's users to keep track of any substantive changes to the package. |
|
I strongly support this proposal, and I'd like to see an agreement reached on the path forwards as soon as possible. I don't have strong opinions on the actual mechanisms; I think that's best left to those who are more familiar with the workings of Hackage and cabal-install, since those are the tools that will have to work with whatever new mechanisms are introduced. Perhaps we can first agree on some principles:
|
What would be the reason to keep the lower bound requirement? It should be the same level of complexity to infer lower bounds as upper bounds, and given how common forgotten lower bound bumps are in practice, I'd find this more reliable. |
The thinking here is that lower bounds can be known at release time and don't change for a given release, so it makes sense to put them in the That said, I understand the point that the author might prefer to have a tool check which old versions of each dependency actually compile. So long as the author understands the risks, I don't see anything wrong with allowing lower bounds to be omitted too. |
|
Just to clarify my point slightly: I'm taking it further than what an author might prefer. From personal experience and experience working with other packages, it's very common to:
|
|
Good point. Automated testing can discover incorrect lower bounds, and in that case the inferred bounds would be correct - so solving would work - but we should also notify the author/maintainer that the lower bound in the .cabal file was found to be wrong. Similarly, if we discover that there's a concrete upper bound, because the package doesn't compile with some new release of a dependency, we can notify the author about that too. The author doesn't have to do anything, but they could put those constraints into the .cabal file if they wanted to, which would speed up future tests and serve as documentation. |
|
@simonmar I think its worth spelling out the motivations for keeping the automated stuff out of cabal files. Here's my run at it: 1) cabal files should be what the author (or maintainer) put there, not automated information. 2) cabal file revisions bloat the package index. On the other hand, here's what I can think the other way (i.e. integrating this into revisions) 1) Original cabal files are always there, this is just layered on top and integrated so cabal-install doesn't need to know about this system. 2) If not cabal files, we'd have to put metadata about known bad bounds into another file, which the cabal-install tool could read. That other file should also grow monotonically over time, to enable reproducibility. So now that other file looks technically just like a package index anyway... Listing this stuff out, I don't think there's a compelling case either way yet, but my gut tells me it would be technically easier to tweak our existing revisions mechanism than any other approach. Let me throw out another rough suggestion:
Packages uploaded to hackage get tested whenever any of their direct deps has a version bumped, and built with that dep pinned to the latest version. A) If they fail to build, but an upper bound would normally have prevented that plan, nothing happens. B) If they succeed in building, and no upper bound would have prevented the plan, nothing happens. B) If they succeed in building, but a bound would have prevented the plan, update information in the page to note this, prepare a "draft" revision to cabal metadata that can be accepted with a single click, and email the maintainer. C) If they fail to build but an upper bound would have prevented the plan, do likewise.
Maintainers may choose for any or all their packages to A) opt out of getting any emails, B) get emails with explicit approval of bounds changes as above or C) have autodetected bounds changes automatically applied and get emails with notifications of such changes. (as per the above, the relevant portions of the logic can apply to lower bounds too -- with the caveat that for some packages, certain combinations of lower bounds can be untestable absent e.g. old compilers. for example, there are many packages that will still claim to build against very old versions of base! so some heuristics will need to be hashed out...) (also note that the above proposal that forces a build of all direct revdeps of a package whenever it is bumped is already sort of scarily resource-heavy. i think its a good goal to aim for, but some clever engineering, tradeoffs and heuristics may be needed to make a tractable version of this sort of system. one such heuristic would be for example -- we only check the most recent version of each revdep, rather than all versions.) |
But the "layer on top" is some kind of metadata stored in Hackage, right? LIke the current layering of modified .cabal files. So these two schemes only actually differ at the cabal-install level. At the Hackage level, we still have original .cabal files plus some extra automation-inferred stuff. I don't really have strong feelings about how this is implemented, but I think it's important that the inferred constraints are visible and clearly separated from the pristine source. If something is magically changing .cabal files, it seems to me too surprising. Otherwise I agree with your two rough suggestions. |
|
"cabal install should build the same thing as cabal get followed by cabal build." -- this is as far as I know how it works at the moment. The modified cabal file with updated bounds is substituted for the original when the package is unpacked, and the tarball itself remains intact. We could actually use better signaling in this regard. So the key point is UI i think, and in particular: "I think it's important that the inferred constraints are visible and clearly separated from the pristine source." I agree. Consider the current hackage page for a package with metadata revisions -- here's a recent revision I picked sort of arbitrarily: http://hackage.haskell.org/package/distributed-process-0.6.6 Under the "Uploaded" line there is an "Updated" line with a date and a link to the revision information, which looks like: http://hackage.haskell.org/package/distributed-process-0.6.6/revisions/ It seems two possible improvements are in place for hackage (at least). First, finding a better way to indicate what "Updated" means and perhaps making it more obvious? Second, perhaps improving the output of the revisions display information? Now as to cabal -- perhaps when it swaps in the revised cabal file for the original, it could preserve the original somewhere obvious, and print a notice that the original is at e.g. foo.cabal.original and the foo.cabal file contains updated metadata? At the one point I agree this should be obvious in the UI. But at the same time we want a streamlined UI that doesn't throw information at users that they don't need, and drown them in detail. So I think some further consideration of what such a UI would look like is necessary, and the ideas I've tossed out here feel ok, but not especially clever in this regard... |
|
I view cabal (or any package manager) is a necessary annoyance. However the overarching goal should be to make me have to deal with it the least. My priority is designing and building software to express ideas or business needs (e.g. managing packages), not dealing with a package manager. Hence the package manager should strive to be as invisible to my workflow as possible, it should just work. That's what I want from a package manager. Therefore I'm in favour of automating anything that can be automated. |
Right, but the surprising thing then is that what you get with
Sure. The details of the mechanism, whether to modify .cabal files vs. having a separate file is a bit of a rathole that I don't really want to get involved in, aside from the points I've already made. I'll leave it up to your (and others') good judgement about how to represent and store the metadata. I think we're in general agreement about the high-level goals. |
|
A slightly orthogonal proposal: Today I noticed that stack-1.3.0 prints: I guess So based on that, why we don't try the "no upper bounds" approach first with stack and stackage. Whenever More convervatively, it could omit upper bounds only for packages without revisions (or bounds-shrinking revisions), as the fact that revisions are made witnesses that someone cares about them (author or trustees). The pros:
The cons is that it's not clear which bounds are meant to be there from the beginning, and which are speculative, so this is in some sense another extreme. But still, this feels to be much cheaper (both in engineering effort, as well as in reversibility) experiment. |
|
One of the things that I feel often derails conversations like these are a few very hard cases that are difficult to handle in generality. (SPJ has once told me, "hard cases make bad law") Here are a few:
So, I suggest that we limit ourselves to designing a system that works well, assuming:
With some escape hatch for dealing with packages that don't fall into this mold; ideally, we should gracefully degrade into the state of functionality we have today. In particular, upper bounds automation should cause these packages to become unbuildable if they were buildable previously. |
I think the problem could be made more tractable, or at least decoupled, if we first focus on a mechanism that can manage the contentious bounds outside the cabal file, initially using heuristics as above, which then allows the process of automating bounds management to proceed at its own pace, with benefits flowing through as they arise. |
|
Let's talk a little bit about mechanism. How do we deal with pre-existing upper bounds on Hackage? The problem is that when you see an upper bound Hackage, how do you know if it is a real upper bound borne from someone's conscious decision, or simply a speculative upper bound? This is not annotated, so we have to either ask users to fill this information in or guess. There are two ways to guess:
As far as I can tell, (1) seems less likely to break things, although it requires systematically undoing the hard work of those maintainers who have kept their upper bounds up-to-date. There is also a syntactic problem with how to let maintainers declare a bound to be real or speculative; any extension needs to avoid causing old versions of Cabal from choking. Perhaps the most practical solution is to introduce a new field declaring which packages upper bounds are real/speculative, since Cabal will ignore such fields. Who has the rights to edit implicit bounds? I can think of a few groups of users:
Option (4) poses unique challenges since we could be spammed with spurious version bounds, but it is also known that wikis works surprisingly well: they place the ability to upload information in the hands of those who care (because it is the end-user who, at the end of the day, cares that the bounds are accurate.) This could also become a way for users to submit build logs, or even for GHC developers to collect telemetry. This is related to the next question: Where are the implicit bounds stored? Once again, there seem to be two primary strategies:
I am a little afraid about overengineering here, but there is something very attractive in having a federated series of databases; this means any set of organizations can run builders and contribute bound information; a wiki-like service could collect information its own way. If we design some protocol for federated databases and implement it in cabal-install/Stack, people can go off and implement their own builders/server-side solutions without having to block on some centralized infrastructure. Storing the bounds as a series of Hackage revisions is appealing, in the sense that it can in principle be implemented without any modifications on top of Hackage. However, it basically fixes the set of users who can edit bounds, and for extra automation we would need to programatically submit revisions. How are the implicit bounds applied. In the conversation thus far, I've only seen Cabal file editing suggested as the mechanism for applying these bounds, but this is definitely NOT the only choice we have: if you pass |
|
THIS PROPOSAL IS OBSOLETED SEE BELOW. A proposal. Here is a proposal that falls under the following parameters:
The main idea is that we introduce the notion of a build log as essential evidence that a package has accurate bounds before it can be uploaded to Hackage. A user can manually generate build logs, but more likely they'll ship their candidate release to a build farm which generate the logs for them. A build log is the transcript of building a package under some version configuration. At minimum, it must contain the versions of all transitive packages that were built with it, the constraints it was solved under, and the timestamp of the index it solved against. It would also be nice if it also actually contains the verbose output of GHC actually building the package. A build log can either be successful or failing; failure can either be due to a build failure, or solver failure. Suppose that your package has the dependencies You need the following logs of builds of your own package to demonstrate your bounds are accurate:
The general rule for failing logs is that for each dependency, we move it just out of your given dependency range, find a dependency solution that is otherwise consistent with your constraints (the solver preference tries to keep the other dependencies within our bounds), and see if it builds. (If it builds successfully, that means your constraints are too restrictive.) Furthermore, for every reverse dependency of your package, you must provide an either successful or failing build log with your package pinned against the version you are about to release (ignore other constraints on it). You are exempt from this requirement if the reverse dependency was failing with the previous version of your package. Prior to uploading to Hackage, we perform edits to the upper bounds of each reverse dependency, bumping the upper bound to include our new version if the log was successful or restricting the bound if it was not. Then, we upload our new package. |
|
I think this build log proposal is solving the wrong problem. It says "you must provide" repeatedly -- so it solves the problem of making package bounds verifiable. This is an interesting problem to solve in some distributed way. But the way it does so is by placing more burdens on package authors. The goal of this current round of discussion, I think, is to find a way to lighten the burden on package authors by making some of their bounds management automated -- so that they can consider such issues less, or not at all -- not more. There is a lot of stuff in this proposal that might be automated for verification of bounds at some future point, but I don't think doing any of it moves the needle on the things that are motivating the current discussion. |
Two points: First, I think it is useful to think about the problem in terms of verifying bounds, rather than inferring bounds, because the verification problem is easier, and gives you a place to start for inferring them. For example, supposing that you have some existing, known-good set of bounds; if verification fails then you can bump the bounds and try again. You can use verification to implement inference, and I don't think anyone else in this proposal has actually said anything about how inference is going to work. Second, I think it's important to consider how the "workflow" of such automation occurs. My observation is that implicit bounds generally need to be updated when a release of the dependency occurs. So it seems to me like the workflow should be (I'll use the "inferring" nomenclature to avoid the confusing from point 1):
I suppose you can ask when (1) and (2) should happen. In the wording of my proposal, they need to happen before a package is uploaded. It sounds like what you have in mind is that these updates should happen asynchronously with the other upload. That adds more constraints: whatever the state of implicit bounds, it needs to be such that adding a new package with missing bounds information will not break previously working dep solving runs (otherwise we are back in the situation where someone uploads a BC-breaking package, and then everyone's projects break because the solver starts using it even though it's not compatible.) So if bounds inference is going to be asynchronous, that implies that you need to apply an implicit upper bound on every package, and furthermore, that no one can use the package without To summarize, it's important to think about when bounds get calculated and uploaded, because if you care about dependency solving continuing to work when new packages are uploaded, it is a very different matter if you can assume the bounds are updated prior to the new package being uploaded, or some later period of time after the upload. |
|
One way of managing the asynchronous update would be to have an explicit process of choosing to move an index forward to a newer version. And more importantly the ability to fix it to the prior known good state. Which I understand is now possible. So it could end up with some kind of rolling snapshot, and when certain stability criteria are met it becomes generally used. |
Reading this, I wasn't sure if you were suggesting that we continue maintaining the Hackage index as it is today, but with some revisions marked as "known good", or if you were suggesting something more complicated. One thing I worry about with the former strategy is that, if people are continuously adding new packages and then it takes days-weeks to get correct bounds on them, there may never be a time when the entire index is actually "good". Reflecting on this, there is another choice too: if we can distinguish between known-bad and preemptive upper bounds, then when a new version of the package is uploaded, the user can either run the solver to enforce or ignore preemptive upper bounds. One possible workflow is that when users update their index, by default they ignore preemptive upper bounds, but if a build fails, cabal can mention, "By the way, you're using an untested package; try If you're still implementing this as Hackage revisions, you need to add an extra field to Cabal files to distinguish between these two types of bounds, and you need a default policy (preemptive or known bad?) with pre-existing upper bounds on Hackage. If you're implementing this as an external database, the database can just report, for a given dependency, if there is a known bad bound. |
|
"In the wording of my proposal, they need to happen before a package is uploaded." -- if is could happen automatically with no work from the author, but still on the author's machine, then sure. But that only works for the package the author is uploading. What about all the packages that depend on it? Surely that should happen in a centralized way. That said, we can draw a distinction between "package is in the main index" and "package is just a candidate or the like" and maybe say that authors can upload candidates with auto-promotion, and only after bounds inference of all affected packages do those candidates get auto-promoted. To me I could go either way on that, but I lean towards not having that complexity, because I think the goal of hackage having all good bounds all the time is not feasible, and instead it just needs to sort of keep improving and adapting over time. With regards to "whatever the state of implicit bounds, it needs to be such that adding a new package with missing bounds information will not break previously working dep solving runs" i disagree. Uploading a new package can always mean that downstream packages break -- a lot more can change to break things besides just the API. It seems like a sort of arbitrary monotonicity criteria that we have never managed to enforce in the past, as you note. So again, working to enforce it now seems like we're targeting the wrong problem -- which is not inconsistent bound information on hackage, but rather that keeping decent bound information is too hard for authors. Unless proposals address author ergonomics first, then they're worth considering for other reasons, but not for addressing the concerns in this thread. (sorry for being so single-minded here, but because there's a lot of focus on this issue, i'm particular concerned about trying to keep discussion focused on what i think the core problems that people are experiencing friction with at this time). |
|
I think if we accept that a) the speculative bounds should be managed outside the cabal file, and Then choosing which separate database to use becomes a separate management process. In one case, a stackage snapshot could be represented as a database. In similar fashion, there could be some concept of a stable database, and a currently being stabilised one. In other words, there could be a generalisation of the stackage concept from single point releases for each package to known good ranges. No details, just concept at this point |
The prevailing attitude is that if I release a package, I should not be responsible for finding out which downstream packages I have broken by performing this release. I think it is very interesting to consider what would happen if we did force a package author to rebuild all the packages that depended on it whenever it did a release. Perhaps responsible package maintainers would embrace tooling that make it easier for them to check if their new release is breaking half the world. They can always say, "I don't care about the breakage, this BC break is for your own good, add this upper bound and fix your code later", but at least it was an informed decision. If there is incentive for a package author to run these builds, I don't see why not let them do so, rather than assume that everyone is too lazy and a central service must be brought up. I think a centralized package builder is unrealistic in its own way, in that it is very possible that we simply do not have the bandwidth to repeatedly rebuild all of Hackage every time there's a new release of bytestring. (This is also why the public option is also appealing: bounds data will come in from people who care about; i.e., precisely the people building the packages.)
So, what is the goalpost here? Before we talk about what is practical, let me posit the ideal: Soundness. If the dependency solver determines that an install plan is compatible with the version bounds of the packages involved, this plan will successfully typecheck and compile. (I shouldn't get non-buildable install plans.) Completeness. If the dependency solver determines that an install plan is not compatible with the version bounds of the packages involved, it is because this plan does NOT successfully typecheck and compile. (My bounds shouldn't prevent me from getting install plans that work.) The reason we don't try for this is because there are exponentially many install plans consistent with bounds, and we simply cannot solve them all; additionally, since the solver prefers later versions of packages, there isn't any reason to believe any of these plans will actually show up in practice. In practice, here is what people care about:
But these goals are in tension with each other. You cannot achieve goal (1) unless you preemptively add upper bounds, because there really is no reason to expect that new version will work. And you cannot achieve (2) and (3) unless you are proactively updating upper bounds upon releases of dependencies. OK, so new proposal coming in the next comment. |
|
Proposal. For simplicity, this proposal assumes that the existing structure of a dependency in Our proposal is to maintain a database of the following bounds:
Like the Hackage database, this database is monotonically increasing, so that we can refer to snapshots of it in time. (It is possible for this database to be done using Hackage revisions although I am not so sure this is a good idea.) Before we specify how this database is populated, let us first describe how it is used by end-users.
OK, so how is this database populated and updated? First, let's assume that we have an existing database with accurate hard and advisory bounds. The advisory upper bound gets increased if you have a successful build while violating the advisory bound (eventually relaxing the author-provided upper bound); the hard upper bound gets set if you have a failing build while violating the advisory bound. The hard upper bound update case is a little tricky, because if you have two packages beyond the advisory bound, either of them could be the culprit. You will need to do point-wise tests to find out which was the actual problem. These builds can come from a number of places:
How do we populate this database? The author-bound is initialized to the
|
|
Please consider including a feature to allow authors optionally to delegate their dependency bound update permissions to a list of others either for a limited period or an open-ended period. I can imagine this being used when the author is away or busy. |
|
@hgolden Yes I don't see why not. One challenge with a separate database is we need to figure out how the authorization story works. Probably don't want to block on making Hackage an identity provider... |
|
In the previous proposal, I assumed that the successful or failing build, updating the advisory bound, is the gospel of truth when it comes to whether or not a package is compatible with some dependency. But this is not actually true: a new release may have subtle semantic or performance changes that make it unusable for end users. Two prominent examples (h/t @hvr):
In events like these, what happens with the proposal I have set forth? Initially, default builds (without If you want to avoid breakage of this form, then it is essential that the process for bumping advisory bounds account for the possibility of semantic/performance change. There are a few ways to do this:
The impression I get is that people are primarily opposed to builders automatically bumping the version bounds that people use by default when they run the dependency solver. (I don't think they are opposed to recording the information that it happened to build correctly, nor do I think they are even necessarily opposed to giving people the ability to ignore author bounds and just trying out whatever is known to build.) But it's also important to acknowledge that human only process can and will get things wrong, and should not be depended on if latency (getting a newly uploaded package usable as quickly as possible) is the top priority. So it's not clear to me if forcing (2) would unacceptably increase latency, or actually be OK in practice. With absentee maintainers, the latency, even of a simple "approve" click, is effectively infinite (and we don't want people rubberstamping these things: the point of having a human in the loop is to notice if something awful is happening.) |
|
One possibility is something that is "halfway to" 2. Just don't automatically apply advisory bound relaxations unless they're author approved. (And the easy way for an author to approve them is to, perhaps with a button-click, accept them back as cabal-file revisions). So if I wanted to have unapproved advisory bounds applied to my build, I'd need to run with a flag "--allow-unapproved-advisory-bound-relaxations" or something perhaps a bit less wordy. |
II think this discussion should start with what we want This is for the obvious reasons: good systems are built in layers, So what do we dependency bounds in One answer is what they mean now: that all versions within that bound are absolutely approved, regardless of whether the package compiles or passes tests with them. Frankly this doesn't make sense. What author wants to say, "these version of this dependency are valid, even if my package doesn't compile with them?" Even if such an author existed, why would we want to help them communicate this clearly malicious idea? IIWe should change the meaning of This makes far more sense as something we want to allow people to communicate. It also allows us to solve the semantics & performance issue @ezyang mentioned above. Sidenote: ezyang mentioned that we could improve our ecosystem by using better ways to do machine verification of the APIs of dependencies. While this is an awesome idea and I'm totally behind it, I'm suspicious that things will always slip through the cracks. Sometime we'll need the ability to exclude specific versions of dependencies for semantic or performance reasons, and this will continue to be the case for the foreseeable future:( So under this system semantic & performance bounds would be tracked in the III(The caveats section). Instead of making Also, I realize that not having bounds on a lot of dependencies may make it hard for the solver, so perhaps this new meaning for bounds should only apply to upper bounds. Other people will know more about this. Finally, thanks to @ezyang who encouraged me to mention my concerns in this thread. |
|
Summary of the conversation thus far: General ideas about what a solution should do:
Commentary about the way things are today
Where should the revisions be stored?
Proposals
|
|
Here's my current proposal. For each libraryThe meaning of both upper and lower bounds in
This is roughly in line with Simon Marlow's ideas:
and
This is slightly different than Marlow's proposal:
... because putting an upper bound on a dep doesn't eliminate automatic upper bounds for that dep, only layers over it. But I think it's a good change, because I like how consistently it allows the meaning of library bounds to be stated. Also, note that library authors can continue exactly like nothing's changed, if they wish! They can still use bounds to express what packages compile and test as well as what versions are semantically approved. Frankly though, I think in general they will be better off letting automation handle as much as possible, which leads to the next part... On Hackage(This part I'm not sure about) How would we feel about removing in-place package revisions? This would have two benefits: Firstly, One disadvantage of this is that we'll lose the ability to make other small fixes in EDIT: I realize the UI for package revisions won't be an exact fit for modifying extra-bounds information, but it should be a good start. I would be happy to help with this. Also, once this is done then the process for automatically modifying that extra-bounds information could begin to be automated, but that wouldn't have to be done all at once. |
|
Basically the more I think about this issue the more I think the need has already been felt and been partially solved by mutating Haskell packages in place. So I think the full solution should start by building on that and making it more principled. |
|
@gbaz (December 13, 2016)
I believe it would be helpful if the /revisions/ display information were available to (automated) tools that might want to query the update history. This could be done using XML (rather than the HTML display used currently) so it could be parsed by tools. Alternatively, you could provide this sort of information with a web API that returns JSON to the caller. |
A json rendering of the revisions exists: http://hackage.haskell.org/package/distributed-process-0.6.6/revisions/.json It doesn't display the calculated changes between each set. But it does let you figure out which files to query to get the cabal file for each set yourself, and then parsing those and diffing them can be done easily with existing libraries. |
This proposal aims to clarify the actual technical issues around managing version bounds in cabal files.
The intent is to come up with a solution via discussion that works for the cabal solver, and for stack, and does not place an undue maintenance burden on package maintainers.
The formatted version can be seen here