"Missing file" error doesn't tell me where I attempted to import a file from

[ocharles]

Running dhall-to-cabal...
dhall-to-cabal: 
↳ ./dhall/empty-package.dhall 
  ↳ ./dhall/Extension 

Error: Missing file dhall/Extension

I know the error is in empty-package.dhall, but I still have to go do some hunting. Having the line and column number would be much more useful.

[Gabriel439]

So I took a stab at this and it's possible but requires breaking changes to the API for exprFromPath and friends (to thread a new argument for the Src span). Given that there are already a lot of breaking API changes in this release I'm going to hold off on this for at least a couple of releases

[ocharles]

Hmm, do we not want to minimize the frequency of breaking changes? As a user, I'd personally prefer one breaking change rather than many, even if it's a bunch of things to fix. Dhall is in its infancy after all, but as I evangelise it more, subsequent major releases could affect more people than they do know. Just my 2c.

[Gabriel439]

I try to minimize breaking changes to the language by:

• requiring approval via the standardization process
• structuring them in a way that the vast majority of code still compiles
  • example: new constructors keyword is technically a breaking change but won't affect most users

However, for the Haskell API my policy is the same as all of my other Haskell libraries:

• Cut a release roughly every month, only publishing more frequently for:
  • Major bug fixes
  • Fixing upper bounds for Stackage
• Try to spread out breaking changes

To understand the rationale for this policy, consider the following two scenarios:

• Scenario 1: I cut a release with 1 breaking change and some new features and then cut a second release with another breaking change and some new features
• Scenario 2: I combine both releases into a single release

First, scenario 1 is no worse than Scenario 2 for one main reason: downstream consumers of the API who prefer Scenario 2 can accomplish the same thing underneath Scenario 1 by just skipping the first release and upgrading directly to the second release.

Additionally, Scenario 1 has advantages:

• Users have the option to migrate to the latest release in two smaller steps instead of migrating in one big indivisible step
• The smaller the steps are, the easier to roll back changes if something goes wrong
• Users can take advantage of features in the first release without having to immediately pay for the migration cost of the second release

There's also a process-related reason that I don't try to bundle as many breaking changes into one release as possible, which is that it discourages timely releases and deteriorates quality assurance.

For example, you typically end up in the following cycle where:

• you start by accepting one breaking change for a release
• you create an incentive to delay cutting the release so that more breaking changes can come in "under the line"
• this creates a bias towards creating even more breaking changes ("we might not get another breaking release for a while so let's break everything while we still can")
• these additional proposed breaking changes are expedited and don't get properly reviewed and tested ("we're already behind schedule with our current release")
• you get a large, disruptive, and buggy release
• people become reluctant to approve new breaking changes to the language due to fear of repeating the above process
• by the time you finally overcome that reluctance to approve another necessary breaking change you've accumulated too many proposed breaking changes in the queue
• now repeat this vicious cycle with an even larger set of breaking changes that you have to flush from the queue

[ocharles]

Scenario 1 does not help me if I need something that has a solution but didn't make the cut for the first major release. Now I'm arbitrarily either spinning my wheels, or having to go out of my way to work on HEAD. So scenario 1 is, in a sense, worse than scenario 2.

Users have the option to migrate to the latest release in two smaller steps instead of migrating in one big indivisible step

Assuming that the changes are independent. If you cut a small major release and then have to revert that change, you may waste your user's time.

I don't really buy any of the arguments in that process list, that's all extremely hypothetical and many points in that flow have decisions and can have policy around them.

I don't mean this negatively, this is ultimately your project and you are free to manage it however you want 😄 I'm happy to wait for this feature if that's what you feel is best!

[Gabriel439]

Scenario 1 does not help me if I need something that has a solution but didn't make the cut for the first major release

The assumption is that both Scenarios take the same amount time to release the second batch of breaking changes. The first batch of breaking changes come earlier in Scenario 1. The difference between the two is that you didn't delay the first batch of changes in Scenario 1 to avoid two consecutive releases with a breaking change to the API .

I understand that this is not a negative discussion (I didn't take it as one), but it's still a discussion I find interesting 🙂

[ocharles]

@Gabriel439 you say:

So I took a stab at this and it's possible but requires breaking changes to the API for exprFromPath and friends (to thread a new argument for the Src span). Given that there are already a lot of breaking API changes in this release I'm going to hold off on this for at least a couple of releases

Is this work on a branch anywhere that could be pushed for others to collaborate on? Or have things changed to the point where this is no longer a relevant issue? I forget what the error looks like - but I've probably got used to just reading the import hierarchy above!

[Gabriel439]

@ocharles: As you commented in #561 I think that we should let #561 supersede this ticket since that has the more detailed summary of what changes need to be made. I don't have a specific branch, though, just the notes that I left on that ticket

[ocharles]

Cool with me!