Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
ocharles opened this Issue Jan 22, 2018 · 8 comments

Comments

Projects
None yet
3 participants
@ocharles
Copy link
Collaborator

ocharles commented Jan 22, 2018

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

This comment has been minimized.

Copy link
Collaborator

Gabriel439 commented Jan 23, 2018

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

This comment has been minimized.

Copy link
Collaborator Author

ocharles commented Jan 23, 2018

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

This comment has been minimized.

Copy link
Collaborator

Gabriel439 commented Jan 23, 2018

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

This comment has been minimized.

Copy link
Collaborator Author

ocharles commented Jan 23, 2018

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

This comment has been minimized.

Copy link
Collaborator

Gabriel439 commented Jan 23, 2018

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

This comment has been minimized.

Copy link
Collaborator Author

ocharles commented Oct 28, 2018

@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

This comment has been minimized.

Copy link
Collaborator

Gabriel439 commented Oct 28, 2018

@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

This comment has been minimized.

Copy link
Collaborator Author

ocharles commented Oct 28, 2018

Cool with me!

@ocharles ocharles closed this Oct 28, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.