Comments (17)
AFAIK, build-tools
doesn't support git
, so this won't work. (Note: it also requires python2
.)
I'm not sure what would be the best way to handle this. Maybe there's a way to do this with a custom Setup.hs
but I feel that's going out of the way. I'm not familiar with Nix – is there a way to specify extra dependencies outside of the .cabal
file?
from directory.
AFAIK, build-tools doesn't support git, so this won't work. (Note: it also requires python2.)
Doesn't cabal just ignore the tool if it can't find it and prints a warning about it? If not then maybe we have to patch that first.
I'm not familiar with Nix – is there a way to specify extra dependencies outside of the .cabal file?
The practice on NixOS
or rather the main package repository, nixpkgs
, is that Haskell expressions are generated automatically out of the cabal files so we rely on them to state their dependencies. There is a way to work around this on nixpkgs
side (or rather in the tool that does the translation) but tickets like this are created in hopes that the package maintainers can fix the issue on their end. So in the end it'll hopefully find its way into the cabal file where we can pick it up.
from directory.
AFAIK, build-tools doesn't support git, so this won't work.
Just use the following snippet as Setup.hs:
module Main ( main ) where
import Distribution.Simple
import Distribution.Simple.Program
main :: IO ()
main = defaultMainWithHooks simpleUserHooks
{ hookedPrograms = [ simpleProgram "git" ]
}
from directory.
Doesn't cabal just ignore the tool if it can't find it and prints a warning about it? If not then maybe we have to patch that first.
It seems to just die when that happens.
I would prefer if it just checked if a command named git
existed as a fallback, although I'm not sure how that would fit in the grand scheme of things.
from directory.
Just use the following snippet as Setup.hs:
Cool, thanks! This seems to work.
Is there anything else required besides git
and python
?
from directory.
It's hard to tell ...now that git
has become available, the test suite fails because it tries to access the network:
running tests
Running 1 test suites...
Test suite test: RUNNING...
Cloning into 'dist/testsuite/ghc'...
fatal: unable to access 'https://github.com/ghc/ghc/': Couldn't resolve host 'github.com'
Test suite test: FAIL
Test suite logged to: dist/test/directory-1.2.2.0-test.log
0 of 1 test suites (0 of 1 test cases) passed.
Just for kicks, I tried running out without the network isolation, and then it said:
fatal: unable to access 'https://github.com/ghc/ghc/': SSL certificate problem: unable to get local issuer certificate
Test suite test: FAIL
Basically, accessing the network is a problem in fully automated builds (like we run in NixOS).
from directory.
How about if I just put the tests behind a flag and leave it disabled by default?
from directory.
We can disable them by default ourselves but the goal is to have the tests run (otherwise they are useless) if possible :)
from directory.
Yes, @Fuuzetsu is right. We can disable the tests in Nixpkgs; you don't have to worry about that.
It would be great, though, if those tests that work locally could be split from those that require network access. Then we could run the local tests in NixOS, but avoid those that access github.com. If those two kinds of tests were in separate binaries, then this would be quite easy to accomplish in Nix.
from directory.
For reference: NixOS/nixpkgs@a4ffd58. Tests are now disabled, and the build succeeds in Nixpkgs.
from directory.
The reason why it needs network is to download the GHC repo that contains test suite. Without it no tests can be run. (See this issue.)
Perhaps I should just disentangle the test suite and embed it within network?
from directory.
Well, we have a fundamental assumption in our build process that downloading the release tarball is enough to build the package. If directory
needs additional code to run the test infrastructure, then IMHO the proper way to deal with that would be to package that code on Hackage and to depend on it. I'm not sure whether that's a realistic route to go at this point; I know nothing about the GHC test framework. I've always used hspec
, which worked great for my purposes.
from directory.
The GHC test suite lives in the source tree of GHC – i.e. it's not an isolated library so I'm not sure how feasible it is to upload it to Hackage (it's not even in Haskell either).
from directory.
OK, I've embedded the test framework within the package (Rufflewind@59afb58). While python
is still needed in build-tools
, git
is no longer required.
Would you mind checking again on NixOS?
from directory.
Looks like which
is needed too. The changes can be found here: Rufflewind/directory@7233248...06bc5b9
I made a paltry attempt to build it on a NixOS VM and the package seems to work now. If there are any more related problems, feel free to reopen this issue.
from directory.
Will you make a new release with those fixes?
from directory.
Done: v1.2.2.1.
from directory.
Related Issues (20)
- Function to find executable scripts (not .exe) on PATH (cygwin) HOT 4
- doesDirectoryExist prints stacktrace when `+RTS -xc` HOT 2
- canonicalizePath and makeAbsolute keep ".." HOT 1
- Support time-1.12 HOT 3
- get/set current directory is not consistent on Mac Big Sur HOT 3
- removeDirectoryRecursive failures on Windows HOT 4
- renameFile across drives fails on windows HOT 2
- removePathForcibly can affect the permissions of files outside the path being deleted HOT 2
- Some haddock links are to internal modules
- Support `AbstractFilePath` HOT 1
- isExecutable is not exported HOT 1
- export furnishPath or toExtendedLengthPath in Internal module? HOT 1
- Release for GHC 9.4.1 HOT 3
- Documentation for `doesFileExist` lies HOT 4
- File metadata API with symlink-awareness
- Unhelpful error with `copyFile` into non-existent directory HOT 2
- `directory-1.3.8.0` violates the Haskell PVP HOT 12
- Updating the CI and the cabal file HOT 2
- makeAbsolute ~ gives wrong path HOT 2
- Release for GHC 9.6.1 HOT 3
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from directory.