-
Notifications
You must be signed in to change notification settings - Fork 130
Pass on files and excludeFiles from config to registry #967
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
Closed
i-am-the-slime
wants to merge
4
commits into
purescript:master
from
i-am-the-slime:support-exclude-files
Closed
Changes from all commits
Commits
Show all changes
4 commits
Select commit
Hold shift + click to select a range
315137e
Pass on files and excludedFiles from config to registry
i-am-the-slime 29dfda4
Document `files` and `excludeFiles` in README
i-am-the-slime 7931b8e
Add simple test for parsing config
i-am-the-slime 6efc9fe
Merge branch 'master' into support-exclude-files
f-f File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,72 @@ | ||
module Test.Spago.Config where | ||
|
||
import Spago.Prelude | ||
|
||
import Data.Codec.Argonaut as CA | ||
import Data.Map as Map | ||
import Registry.PackageName as PackageName | ||
import Registry.Version as Version | ||
import Registry.License as License | ||
import Spago.Core.Config (Dependencies(..)) | ||
import Spago.Core.Config (Config, configCodec) as Config | ||
import Test.Spec (Spec) | ||
import Test.Spec as Spec | ||
import Test.Spec.Assertions as Assert | ||
import Registry.Location (Location(..)) | ||
|
||
spec :: Spec Unit | ||
spec = do | ||
Spec.it "Parses config" do | ||
case parseYaml Config.configCodec validSpagoYAML of | ||
Left error -> | ||
Assert.fail $ "Failed to parse: " <> CA.printJsonDecodeError error | ||
Right config | config /= validConfig -> | ||
Assert.fail ("\n" <> printYaml Config.configCodec config <> "\ndoes not equal\n\n" <> printYaml Config.configCodec validConfig) | ||
Right _ -> | ||
pure unit | ||
|
||
validConfig :: Config.Config | ||
validConfig = | ||
{ package: Just | ||
{ name | ||
, description: Nothing | ||
, dependencies: Dependencies (Map.fromFoldable (dependency <$> [ "aff", "affjax" ])) | ||
, bundle: Nothing | ||
, run: Nothing | ||
, test: Nothing | ||
, publish: Just | ||
{ license | ||
, version | ||
, excludeFiles: Just [ "src/**/*Test.purs" ] | ||
, files: Just [ "src-extra/**/*.purs" ] | ||
, location: Just $ GitHub { owner: "purescript" , repo: "spago" , subdir: Nothing } | ||
} | ||
} | ||
, workspace: Nothing | ||
} | ||
where | ||
license = unsafeFromRight (License.parse "BSD-3-Clause") | ||
version = unsafeFromRight (Version.parse "0.93.6") | ||
name :: PackageName | ||
name = unsafeFromRight (PackageName.parse "mypackage") | ||
dependency name = Tuple (unsafeFromRight (PackageName.parse name)) Nothing | ||
|
||
validSpagoYAML :: String | ||
validSpagoYAML = | ||
""" | ||
package: | ||
name: mypackage | ||
publish: | ||
version: 0.93.6 | ||
license: BSD-3-Clause | ||
location: | ||
githubOwner: purescript | ||
githubRepo: spago | ||
files: | ||
- "src-extra/**/*.purs" | ||
excludeFiles: | ||
- "src/**/*Test.purs" | ||
dependencies: | ||
- aff | ||
- affjax | ||
""" |
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This PR might not be aiming at implementing the full colocation feature, but I'd like to see it through to get a feel at how complex it is.
Once we forgo the idea that all sources are in
src
and all the test files are intest
, we need more config than this:files
will add source files to the ones insrc
excludeFiles
will remove source files from the ones insrc
test
test
I guess?We'd want (3) and (4) for symmetry if we have (1) and (2), but I question the utility of (1) and (4), as they are not necessary for colocation and I can't come up with non-contrived usecases for having them.
Then something else that we'd need to care about (and that it not yet implemented here) is how we deal with the globs for
src
andtest
in the presence of colocation.This is a good starting point, but there might be more occurrences across the codebase.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was thinking that we could rename the keys to
includes
andexcludes
, and do two passes. First, we add anything fromincludes
to thesrc
we take by default. Then we applyexcludes
to that set (disallowing you from excluding anything you can't exclude, like yourspago.yaml
). Since we don't publish thetest
directory anyway I'm not sure if it's necessary that it has special handling.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Colocation is not only about publishing though, there's building and testing involved in there too. Modifying the config format happens in
core
, and we'd need to think the whole feature through when doing so, which includes thinking about how to include files forspago test
to pick up.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for your input @f-f .
I indeed had not considered testing in this change.
For my personal needs, I need a way to exclude certain files from the libraries I publish.
In particular, these are unit tests, end-to-end-tests any kinds of tests in between. Then there are Story.purs files for storybook that I'd like to colocate but not ship.
I personally don't have a need for excluding what to build. I would want to always compile all
.purs
files in my project including unit tests, stories, and end-to-end tests.I have done this in the past similarly to this:

The problem which I noticed later came when running storybook or spec on an application that dependend on this library it would include the specs and stories from the lib. Not nice.
So I also can't find a use case for 4 in this:
Also here, I'm afraid to question everything at this stage (and I'm probably lacking some background), but is there really this dichotomy of sources and tests? Or does test stand for anything that shouldn't ship?
I personally have quick and slow (end-to-end) tests that I invoke differently (via npm currently), and I have these storybook files which (in my head at least) are more like visual tests without any real assertions.
So actually, I'm not sure from the current
README
how you'd translate a project with variousspago.dhall
files (spago.test.dhall
,spago.e2e.dhall
,spago.stories.dhall
) to the newspago.yaml
format.Would you do this with a small top-level workspace and then subfolders for each of those?
In that case I could imagine a use-case for the files key:
Okay, I'll stop writing here now, maybe it makes sense to discuss this via voice one day so I don't run too far in the wrong direction, and let me know if all this is just draining you and is too annoying.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@f-f What change are you requesting?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I understand your specific usecase, but we can't really afford to just implement a feature that follows a usecase verbatim, or we'd quickly end up with unmaintainable feature bloat - the issue with that is that the interplay between features often incurs quadratic maintenance complexity. Because of this it is worth to take a step back and try to make the feature more generic than what we need right now, so that it could cover more usecases.
In this case, one related usecase that came up at work is that one of the Erlang build tools we use treats the
test
folder in a certain way that doesn't work with FFI, so we'd need to either make thetest
folder configurable, or add a way to add sources forspago test
to pick up. Since Colocation is also very much about "changing what is picked up byspago test
" we could cover both cases with this same feature.It's not a dichotomy as much as a convention. As of today:
src
test
spago run
only includes sources, whilespago test
will include bothsrc
folder - and only that - ends up publishedThe whole premise of this new feature is that this convention needs to go, so things need to be configurable instead.
With colocation our definition of "source files" would change from "
src
" to "src
minus whatever we exclude", and our definition of "test files" would change from "src
+test
" to "src
minus whatever we exclude, plustest
, plus whatever additional test sources"Given the above reasoning, I think we could get away with:
package.build.exclude
key: a list of globs of files to exclude from thesrc
directory, when building and when publishingpackage.test.include
key: a list of globs of files to include when running test (note: these are in addition to the above, and thetest
directory)package.publish.include
key: a list of globs of files to add when publishing (these don't have to be source files), to pass it through to the registryspago.yaml
- we should detect thepackage.build.exclude
key and use the new glob instead of blindly building the whole ofsrc
Yes, I would unpack the end-to-end test to be in its own package, that can be
spago run
when you need it (rather than running every time you need to run tests)There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also, I'm up for talking this through if that helps to unpack things!
Though we should then report back here, so there's a trace of what was discussed and what the reasoning was, for when we want to refer to these in the future
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We’d need a package.publish.exclude, since this issue in particular is more about removing files from src when publishing than it is about including them. So we’d end up with package.publish.include + package.publish.exclude.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agreed, and then we won't need the
package.build.exclude