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

Add support for parsing subdirectories out of git URLs #9

Closed
wants to merge 5 commits into from
Closed

Add support for parsing subdirectories out of git URLs #9

wants to merge 5 commits into from

Conversation

camjackson
Copy link
Contributor

Needed for faradayio/cage#81.

@camjackson
Copy link
Contributor Author

Actually this isn't quite ready yet, I've just found another thing I need to add.

Copy link
Owner

@emk emk left a comment

Choose a reason for hiding this comment

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

Thank you for the patch! I really love the tests.

The design here feels a little bit tricky to get right (because docker-compose.yml is surprisingly complicated), and so I have a number of minor suggestions.

And thank you so much for tackling this; it will be a great feature to have.

/// Determines if two Contexts are equivalent. This is only true
/// if they are the same directory path, or if they are same git
/// repository and branch. Subdirectories of a repository may differ
pub fn is_equivalent_to(&self, other: &Context) -> bool {
Copy link
Owner

Choose a reason for hiding this comment

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

I think we need a better name than equivalent here. It's hard for me to give a sensible name to this function, which makes me suspicious about the design here.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yeah I totally agree. Really, the whole purpose of this function is to figure out whether two sources conflict, i.e. this check. So it's very driven by Cage's requirements, which is to know whether or not two contexts with the same alias are compatible.

Given that it's so Cage-specific, I do wonder if it belongs in cage/src/ext/context.rs? Then it could have a more revealing name, like conflicts_with? The parsing of the git URL could stay in compose_yml, as that is a bit more general-purpose.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Failing that, a better name might be is_compatible_with? It feels a little bit better, though you'd probably still need to read its docs to know what exactly "compatible" means.

/// Extract the repository part of the URL
pub fn repository(&self) -> String {
lazy_static! {
static ref REPO_PARSE: Regex = Regex::new(r#"([^#]*)"#).unwrap();
Copy link
Owner

Choose a reason for hiding this comment

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

It might be a good idea to anchor the leading edge of this regex like ^([^#]*) (or include a comment saying why it's unnecessary.)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

👍

/// Extract the optional branch part of the git URL
pub fn branch(&self) -> Option<String> {
lazy_static! {
static ref BRANCH_PARSE: Regex = Regex::new(r#".*#([^:]+)"#).unwrap();
Copy link
Owner

Choose a reason for hiding this comment

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

Now that I think about it, I'm uneasy about having two different regular expressions that try to parse the URL. It would be better to have a single function that handles all URL parsing, probably with a single regex. Also, the right hand side should probably be anchored with $.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Fair call, I'll figure out the one regex to rule them all.

assert_eq!(with_subdir.branch(), None);
assert_eq!(with_subdir.subdirectory(), Some("myfolder".to_string()));

let with_ref_and_subdir = GitUrl::new(format!("{}{}", url, "#mybranch:myfolder")).unwrap();
Copy link
Owner

Choose a reason for hiding this comment

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

I'm glad to see this test case.

(&Context::Dir(ref dir_1), &Context::Dir(ref dir_2)) => dir_1 == dir_2,
(&Context::GitUrl(ref git_url_1), &Context::GitUrl(ref git_url_2)) => {
git_url_1.repository() == git_url_2.repository() &&
git_url_1.branch() == git_url_2.branch()
Copy link
Owner

Choose a reason for hiding this comment

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

The GitUrl-specific portion of this function should probably be moved to GitUrl, with a name like can_share_checkout_with.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

👍

@camjackson
Copy link
Contributor Author

Ready for next review 🙂

@camjackson
Copy link
Contributor Author

camjackson commented Nov 12, 2017

Ok, change of plans.

As I delved further into faradayio/cage#81, I discovered that when building the Sources object, what I really needed to do is omit the subdirectory part of any git URLs, otherwise those subdirectories permeate through to other places they aren't wanted. So I've added dc::Context.without_subdirectory to do that.

And with that change, the equivalency/compatibility check thing becomes totally unnecessary. Given that it was a bit weird/out of place anyway, I decided to just blow it away.

This branch has become a bit of a back and forth mess now. In hindsight I should have waited until I had figured out how to implement faradayio/cage#81 before opening this PR. I don't want to erase the history here, so I'm going to fix up the git history on a clean branch and open a new PR. This PR can probably be closed.

@emk
Copy link
Owner

emk commented Nov 12, 2017

Closed! Thank you again.

@emk emk closed this Nov 12, 2017
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.

2 participants