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

Fix --offline flag #8676

Merged
merged 20 commits into from
Mar 9, 2023
Merged

Fix --offline flag #8676

merged 20 commits into from
Mar 9, 2023

Conversation

cbclemmer
Copy link
Collaborator

@cbclemmer cbclemmer commented Jan 14, 2023


Please include the following checklist in your PR:

The --offline flag previously created in #2578 but was only implemented for the install command even thought the flag didn't throw an error whenever the build command was run. This PR adds functionality for the --offline flag with the build command.
Additionally there is a new PackageTest for the flag using the build command.

@ulysses4ever
Copy link
Collaborator

Presumably, fixes #5346

@ulysses4ever ulysses4ever linked an issue Jan 14, 2023 that may be closed by this pull request
@cbclemmer
Copy link
Collaborator Author

@ulysses4ever Yeah, I was waiting until I got the tests passing before I pinged anyone

@ulysses4ever
Copy link
Collaborator

No worries! Let's see...

@cbclemmer
Copy link
Collaborator Author

@ulysses4ever I got all the test steps you were talking about before working. The only issue is that when it errors it gives the file the error was called from and that could change later on. Not sure what the best fix for this is because I just sent up the error like rebuildTargets is supposed to do by defining an error BuildOutcome object.

Also as a note, because it's not downloading it from a remote repo I have to test the PackageLocation to be an instance of RepoTarballPackage, RemoteTarballPackage, or RemoteSourceRepoPackage instead of testing whether the BuildStatus is BuildStatusDownload like in the asyncDownloadPackages function (The test is of type RepoTarballPackage).

@cbclemmer
Copy link
Collaborator Author

@ulysses4ever I can probably create a tag like there is for the ghc version etc. to capture error details and that would fix it. I don't think there is anything like that at the moment.

@ulysses4ever
Copy link
Collaborator

I'm sorry I've been running a bit behind on cabal things. I'd have to defer this choice to someone more knowledgeable or just trust you.

@Mikolaj
Copy link
Member

Mikolaj commented Jan 18, 2023

@cbclemmer: I'm thinking, could you have a look at git blame or PR authors of the related code and ping a few previous contributors (unless they are from > 5 years ago, I guess)? If nothing comes out of it, I will try to understand it, advise, merge and we'd depend on feedback from outraged users instead. ;)

@cbclemmer
Copy link
Collaborator Author

@ulysses4ever No worries. I just had an idea and wanted to share. I'll look around the output validator code and see what I can find.

@cbclemmer
Copy link
Collaborator Author

@ulysses4ever I added the tag and now the tests pass. It looks like it was several years ago since the file that normalizes the output was last edited.

Copy link
Member

@Kleidukos Kleidukos left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I guess we can do without the .vscode/tasks.json ;)

Copy link
Collaborator

@ulysses4ever ulysses4ever left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We are getting there!

Also, what's up with cabal-testsuite/PackageTests/MultipleLibraries/T7270/p/Main?

cabal-install/src/Distribution/Client/ProjectBuilding.hs Outdated Show resolved Hide resolved
cabal-testsuite/src/Test/Cabal/OutputNormalizer.hs Outdated Show resolved Hide resolved
cabal-testsuite/PackageTests/OfflineFlag/offlineFlag.out Outdated Show resolved Hide resolved
cabal-install/src/Distribution/Client/ProjectBuilding.hs Outdated Show resolved Hide resolved
elabPkgSourceId = PackageIdentifier { pkgName, pkgVersion }
} = (elabUnitId, Left (BuildFailure {
buildFailureLogFile = Nothing,
buildFailureReason = DownloadFailed . error $ makeError pkgName pkgVersion
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it shouldn't involve error: it's not an exceptional situation like a network failure, or something else out of our control, it's we who are refusing to do something because of the flag -- it's no exception! So, I think, it should be DependentFailed rather than DownloadFailed. Perhaps someone has another opinion.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

DependentFailed needs another package as a parameter this looks like it's used to say that the package that is failing has a dependency that failed. I need to say that this specific package failed while also not producing an exception. Nothing else in the BuildFailureReason data type looked like it suited the problem so I added a GracefulFailure option to BuildFailureReason and it takes a string that will be printed to the terminal without any extra text or callstack, I think anything more specific would clutter up the data type more than is needed.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Full disclosure: I'm no expert in Cabal error types. But, I thought that DependentFailed would work quite all right for this use case. Imagine you depend on 10 packages and 9 of them are in the cache. Then, you may want to know which one wasn't there. On the other hand, if there're two dependencies that are not in the cache then reporting just one is not so nice, perhaps. Although, I could live with reporting one that happened to be the first to be required during the build…

That said, I don't have a strong preference. I'm just not a big fan of changing data types that sound fundamental. Cabal is a library and this would be a breaking change...

@ulysses4ever
Copy link
Collaborator

@cbclemmer just a gentle ping. Great work here, just need to fix minor things...

@ulysses4ever
Copy link
Collaborator

I sense we're getting close. We need reviewers and possibly a backport. I'll add my final review ASAP but we'd need another one.

@cbclemmer
Copy link
Collaborator Author

@Kleidukos I didn't see your review before. It's deleted now. I must have randomly pressed F5 at some point...

@Kleidukos
Copy link
Member

@Kleidukos I didn't see your review before. It's deleted now. I must have randomly pressed F5 at some point...

No problem :)

@ulysses4ever
Copy link
Collaborator

@Kleidukos you requested changes on this PR (#8676 (review)) and I believe they were applied, so maybe you could either unblock it or even approve it?

@Kleidukos Kleidukos self-requested a review March 4, 2023 17:40
Copy link
Member

@Kleidukos Kleidukos left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM! :)

} = do

}
| fromFlagOrDefault False (projectConfigOfflineMode config) && not (null packagesToDownload) = return offlineError
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think you could use notNull instead of not and null separately.

@ulysses4ever
Copy link
Collaborator

@cbclemmer you should feel free to put the squash+merge label now.

Thank you for your contribution, and keep the good stuff coming!!! 🎉

@cbclemmer
Copy link
Collaborator Author

@ulysses4ever Thanks, I looked up notNull on hoogle and I thought it was included in the prelude but apparently it wasn't. I've reverted my changes and now it needs to do the build process again. Thanks for reviewing it

@cbclemmer cbclemmer added the squash+merge me Tell Mergify Bot to squash-merge label Mar 7, 2023
@ulysses4ever
Copy link
Collaborator

@cbclemmer oh my, I'm so sorry! The reason for my mishmash is that I confused it with notElem (which indeed is available from the Prelude).

@mergify mergify bot added the merge delay passed Applied (usually by Mergify) when PR approved and received no updates for 2 days label Mar 9, 2023
@mergify mergify bot merged commit 0ed1218 into haskell:master Mar 9, 2023
@ulysses4ever
Copy link
Collaborator

@mergify backport 3.10

@mergify
Copy link
Contributor

mergify bot commented Mar 9, 2023

backport 3.10

✅ Backports have been created

mergify bot pushed a commit that referenced this pull request Mar 9, 2023
* WIP

* WIP

* WIP

* WIP

* WIP

* add offline logic branch

* Clean up

* Formatting

* Optimize

* Rename test folder

* Add changelog file

* Fix whitespace

* Add <CABAL_ERROR> normalizer tag

* code review changes

* Delet vs code file

* Fix import

* fix wrong output file

---------

Co-authored-by: mergify[bot] <37929162+mergify[bot]@users.noreply.github.com>
(cherry picked from commit 0ed1218)
mpickering pushed a commit to mpickering/cabal that referenced this pull request Mar 12, 2023
* WIP

* WIP

* WIP

* WIP

* WIP

* add offline logic branch

* Clean up

* Formatting

* Optimize

* Rename test folder

* Add changelog file

* Fix whitespace

* Add <CABAL_ERROR> normalizer tag

* code review changes

* Delet vs code file

* Fix import

* fix wrong output file

---------

Co-authored-by: mergify[bot] <37929162+mergify[bot]@users.noreply.github.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
cabal-install: other merge delay passed Applied (usually by Mergify) when PR approved and received no updates for 2 days squash+merge me Tell Mergify Bot to squash-merge
Projects
None yet
Development

Successfully merging this pull request may close these issues.

--offline flag doesn't seem to affect new-build
4 participants