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

YAML parser for Dependency and Target #306

Merged

Conversation

straight-shoota
Copy link
Member

Implements proper YAML parses for Dependency and Target to avoid relying on a hash for storing the mappings. Instead, these types use specific properties now.

Extra attributes are still collected in a hash. This has no real function currently, but it allows for future enhancements with new keys not causing the current implementation to fail reading the data.

/cc #230

Copy link
Contributor

@ysbaddaden ysbaddaden left a comment

Choose a reason for hiding this comment

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

Thanks for tackling this! This is moving into the right direction.

I made a thorought thinking about how they should behave. For example I believe they should only represent SPEC, thus merely hold the values they're meant to (skipping extraneous keys, ...), and be isolated from the rest of Shards (no requirement on resolvers, configuration variables, ...).

Note: it doesn't build anymore.

src/dependency.cr Outdated Show resolved Hide resolved
src/dependency.cr Outdated Show resolved Hide resolved
src/dependency.cr Outdated Show resolved Hide resolved
end

def version
version { "*" }
version? || "*"
Copy link
Contributor

Choose a reason for hiding this comment

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

Why not keep the yielding method?

Copy link
Member Author

Choose a reason for hiding this comment

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

What's the benefit of a yielding method over the nilable? Usage is value { in_case_of_nil } vs value? || in_case_of_nil. The latter is more descriptive.

Copy link
Contributor

Choose a reason for hiding this comment

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

It avoids the nilable union type. This is common in stdlib.

Copy link
Member Author

Choose a reason for hiding this comment

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

A nilable union would still exist unless src/command/check.cr:45 is refactored.

src/target.cr Outdated Show resolved Hide resolved
test/path_resolver_test.cr Outdated Show resolved Hide resolved
test/resolver_test.cr Outdated Show resolved Hide resolved
src/target.cr Show resolved Hide resolved
src/target.cr Show resolved Hide resolved
test/dependency_test.cr Outdated Show resolved Hide resolved
Copy link
Contributor

@ysbaddaden ysbaddaden left a comment

Choose a reason for hiding this comment

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

I still stand to my original opinion to have explicit keys for resolvers.

I'd reduce them to git and path with the parser immediately rewriting the github, bitbucket and gitlab resolvers as a Git URL, raising whenever trying to define git or path multiple times (or concurrently).

That would allow to drop the useless GithubResolver, BitbucketResolver and GitlabResolver classes, yet keep Dependency as close as possible to its SPEC definition.

src/dependency.cr Show resolved Hide resolved
@straight-shoota
Copy link
Member Author

I suppose having only git and path properties and immediately expand specialized resolvers is fine.

The specialized classes could be removed regardless of this change, though.

src/resolvers/git.cr Outdated Show resolved Hide resolved
@straight-shoota
Copy link
Member Author

Rebased on master

@straight-shoota
Copy link
Member Author

Rebased again.

Copy link
Contributor

@ysbaddaden ysbaddaden left a comment

Choose a reason for hiding this comment

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

That's great!

@straight-shoota straight-shoota merged commit b50e333 into crystal-lang:master Apr 13, 2020
@straight-shoota straight-shoota deleted the feature/yaml-parsing branch April 13, 2020 16:00
@straight-shoota straight-shoota added this to the v0.11.0 milestone Apr 13, 2020
waj added a commit that referenced this pull request Apr 13, 2020
taylor pushed a commit to vulk/shards that referenced this pull request Aug 11, 2020
* Refactor Dependency and Target with proper YAML parser
* Refactor git and path properties on Dependency
* Remove specialized git resolvers (GitHub, GitLab, BitBucket) in favour of handling generic git urls
f-fr pushed a commit to f-fr/shards that referenced this pull request Jan 2, 2021
* Refactor Dependency and Target with proper YAML parser
* Refactor git and path properties on Dependency
* Remove specialized git resolvers (GitHub, GitLab, BitBucket) in favour of handling generic git urls
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants