Skip to content

readDesc hook is still not plumbed sufficiently #3552

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

Open
ezyang opened this issue Jul 14, 2016 · 0 comments
Open

readDesc hook is still not plumbed sufficiently #3552

ezyang opened this issue Jul 14, 2016 · 0 comments

Comments

@ezyang
Copy link
Contributor

ezyang commented Jul 14, 2016

Hello @thumphries, you might be interested in this one.

While working on an unrelated refactoring, I realized that the readDesc hook is not being plumbed everywhere it needs to be. To make matters worse, I'm not sure what we can do.

The issue is this code in Cabal/Distribution/PackageDescription/Check.hs, which checks that the .cabal file does not have a byte order mark:

checkCabalFileBOM :: Monad m => CheckPackageContentOps m
                  -> m (Maybe PackageCheck)
checkCabalFileBOM ops = do
  epdfile <- findPackageDesc ops
  case epdfile of
    Left pc      -> return $ Just pc
    Right pdfile -> (flip check pc . startsWithBOM . fromUTF8) `liftM` (getFileContents ops pdfile)
                       where pc = PackageDistInexcusable $
                                    pdfile ++ " starts with an Unicode byte order mark (BOM). This may cause problems with older cabal versions."

No hooks to be found, so they can't possibly be applied here. To add insult to injury, this function gets invoked when you configure. So whatever you were using readDesc for, Cabal is STILL banging on the actual file. (If it even exists!)

@phadej, this is your code. How do you think it should interact with the readDesc hook? Should we drop this code? Or maybe add a hook that passes in the unparsed string of the Cabal file?

EDIT: Or maybe we can add the presence of BOM to GenericPackageDescription and PackageDescription, and then read it off as a pure package check?

ezyang added a commit to ezyang/cabal that referenced this issue Jul 14, 2016
This is primarily intended for use with the Cabal test suite (allowing
us to easily specify multiple Cabal packages for the same Haskell source
files), but maybe some end-users will find it useful as well.  If there
are multiple Cabal files in the current working directory, --cabal-file
(for configure) allows you to disambiguate which one to build with.

There's a big hack to handle the BOM check, as it is inconvenient to
plumb the flag value all the way to the check code.  Some bigger
refactoring needed, see haskell#3552.

Signed-off-by: Edward Z. Yang <[email protected]>
ezyang added a commit to ezyang/cabal that referenced this issue Jul 14, 2016
This is primarily intended for use with the Cabal test suite (allowing
us to easily specify multiple Cabal packages for the same Haskell source
files), but maybe some end-users will find it useful as well.  If there
are multiple Cabal files in the current working directory, --cabal-file
(for configure) allows you to disambiguate which one to build with.

There's a big hack to handle the BOM check, as it is inconvenient to
plumb the flag value all the way to the check code.  Some bigger
refactoring needed, see haskell#3552.

Signed-off-by: Edward Z. Yang <[email protected]>
ezyang added a commit to ezyang/cabal that referenced this issue Jul 17, 2016
This is primarily intended for use with the Cabal test suite (allowing
us to easily specify multiple Cabal packages for the same Haskell source
files), but maybe some end-users will find it useful as well.  If there
are multiple Cabal files in the current working directory, --cabal-file
(for configure) allows you to disambiguate which one to build with.

There's a big hack to handle the BOM check, as it is inconvenient to
plumb the flag value all the way to the check code.  Some bigger
refactoring needed, see haskell#3552.

Signed-off-by: Edward Z. Yang <[email protected]>
ezyang added a commit to ezyang/cabal that referenced this issue Jul 18, 2016
This is primarily intended for use with the Cabal test suite (allowing
us to easily specify multiple Cabal packages for the same Haskell source
files), but maybe some end-users will find it useful as well.  If there
are multiple Cabal files in the current working directory, --cabal-file
(for configure) allows you to disambiguate which one to build with.

There's a big hack to handle the BOM check, as it is inconvenient to
plumb the flag value all the way to the check code.  Some bigger
refactoring needed, see haskell#3552.

Signed-off-by: Edward Z. Yang <[email protected]>
ezyang added a commit to ezyang/cabal that referenced this issue Jul 19, 2016
This is primarily intended for use with the Cabal test suite (allowing
us to easily specify multiple Cabal packages for the same Haskell source
files), but maybe some end-users will find it useful as well.  If there
are multiple Cabal files in the current working directory, --cabal-file
(for configure) allows you to disambiguate which one to build with.

There's a big hack to handle the BOM check, as it is inconvenient to
plumb the flag value all the way to the check code.  Some bigger
refactoring needed, see haskell#3552.

Signed-off-by: Edward Z. Yang <[email protected]>
ezyang added a commit to ezyang/cabal that referenced this issue Jul 21, 2016
This is primarily intended for use with the Cabal test suite (allowing
us to easily specify multiple Cabal packages for the same Haskell source
files), but maybe some end-users will find it useful as well.  If there
are multiple Cabal files in the current working directory, --cabal-file
(for configure) allows you to disambiguate which one to build with.

There's a big hack to handle the BOM check, as it is inconvenient to
plumb the flag value all the way to the check code.  Some bigger
refactoring needed, see haskell#3552.

Signed-off-by: Edward Z. Yang <[email protected]>
ezyang added a commit to ezyang/cabal that referenced this issue Jul 22, 2016
This is primarily intended for use with the Cabal test suite (allowing
us to easily specify multiple Cabal packages for the same Haskell source
files), but maybe some end-users will find it useful as well.  If there
are multiple Cabal files in the current working directory, --cabal-file
(for configure) allows you to disambiguate which one to build with.

There's a big hack to handle the BOM check, as it is inconvenient to
plumb the flag value all the way to the check code.  Some bigger
refactoring needed, see haskell#3552.

Signed-off-by: Edward Z. Yang <[email protected]>
ezyang added a commit to ezyang/cabal that referenced this issue Jul 23, 2016
This is primarily intended for use with the Cabal test suite (allowing
us to easily specify multiple Cabal packages for the same Haskell source
files), but maybe some end-users will find it useful as well.  If there
are multiple Cabal files in the current working directory, --cabal-file
(for configure) allows you to disambiguate which one to build with.

There's a big hack to handle the BOM check, as it is inconvenient to
plumb the flag value all the way to the check code.  Some bigger
refactoring needed, see haskell#3552.

Signed-off-by: Edward Z. Yang <[email protected]>
ezyang added a commit to ezyang/cabal that referenced this issue Jul 23, 2016
This is primarily intended for use with the Cabal test suite (allowing
us to easily specify multiple Cabal packages for the same Haskell source
files), but maybe some end-users will find it useful as well.  If there
are multiple Cabal files in the current working directory, --cabal-file
(for configure) allows you to disambiguate which one to build with.

There's a big hack to handle the BOM check, as it is inconvenient to
plumb the flag value all the way to the check code.  Some bigger
refactoring needed, see haskell#3552.

Signed-off-by: Edward Z. Yang <[email protected]>
ezyang added a commit to ezyang/cabal that referenced this issue Jul 24, 2016
This is primarily intended for use with the Cabal test suite (allowing
us to easily specify multiple Cabal packages for the same Haskell source
files), but maybe some end-users will find it useful as well.  If there
are multiple Cabal files in the current working directory, --cabal-file
(for configure) allows you to disambiguate which one to build with.

There's a big hack to handle the BOM check, as it is inconvenient to
plumb the flag value all the way to the check code.  Some bigger
refactoring needed, see haskell#3552.

Signed-off-by: Edward Z. Yang <[email protected]>
ezyang added a commit to ezyang/cabal that referenced this issue Jul 24, 2016
This is primarily intended for use with the Cabal test suite (allowing
us to easily specify multiple Cabal packages for the same Haskell source
files), but maybe some end-users will find it useful as well.  If there
are multiple Cabal files in the current working directory, --cabal-file
(for configure) allows you to disambiguate which one to build with.

There's a big hack to handle the BOM check, as it is inconvenient to
plumb the flag value all the way to the check code.  Some bigger
refactoring needed, see haskell#3552.

Signed-off-by: Edward Z. Yang <[email protected]>
ezyang added a commit to ezyang/cabal that referenced this issue Jul 24, 2016
This is primarily intended for use with the Cabal test suite (allowing
us to easily specify multiple Cabal packages for the same Haskell source
files), but maybe some end-users will find it useful as well.  If there
are multiple Cabal files in the current working directory, --cabal-file
(for configure) allows you to disambiguate which one to build with.

There's a big hack to handle the BOM check, as it is inconvenient to
plumb the flag value all the way to the check code.  Some bigger
refactoring needed, see haskell#3552.

Signed-off-by: Edward Z. Yang <[email protected]>
ezyang added a commit to ezyang/cabal that referenced this issue Jul 24, 2016
This is primarily intended for use with the Cabal test suite (allowing
us to easily specify multiple Cabal packages for the same Haskell source
files), but maybe some end-users will find it useful as well.  If there
are multiple Cabal files in the current working directory, --cabal-file
(for configure) allows you to disambiguate which one to build with.

There's a big hack to handle the BOM check, as it is inconvenient to
plumb the flag value all the way to the check code.  Some bigger
refactoring needed, see haskell#3552.

Signed-off-by: Edward Z. Yang <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant