Skip to content

Fix file globbing with multiple dots (#784) #1343

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
wants to merge 1 commit into from
Closed

Fix file globbing with multiple dots (#784) #1343

wants to merge 1 commit into from

Conversation

hdgarrood
Copy link
Contributor

Setting the "data-files" field in a .cabal file to pull in
"resources/*.js" would previously not work for any file containing more
than one dot, for example "resources/jquery-1.9.1.js".

This commit changes this behaviour so that a glob counts as a match,
provided that its extension is a suffix of the filename. So, if
resources/ contains foo.js and foo.bar.js:

  • "resources/*.js" will match both "resources/foo.js" and
    "resources/foo.bar.js"
  • "resources/*.bar.js" will match "resources/foo.bar.js" but not
    "resources/foo.js"

It should be noted that I've only tested this by calling
matchFileDirGlob in ghci -- I'm fairly new to Cabal, and can't see how
to test it properly.

Setting the "data-files" field in a .cabal file to pull in
"resources/*.js" would previously not work for any file containing more
than one dot, for example "resources/jquery-1.9.1.js".

This commit changes this behaviour so that a glob counts as a match,
provided that its extension is a suffix of the filename. So, if
resources/ contains foo.js and foo.bar.js:

* "resources/*.js" will match both "resources/foo.js" and
  "resources/foo.bar.js"
* "resources/*.bar.js" will match "resources/foo.bar.js" but not
  "resources/foo.js"

It should be noted that I've only tested this by calling
matchFileDirGlob in ghci -- I'm fairly new to Cabal, and can't see how
to test it properly.
@hdgarrood
Copy link
Contributor Author

refs #784

@23Skidoo
Copy link
Member

Looks good. @dcoutts, can we enable this for all packages or do you want to add a Cabal-version requirement?

@dcoutts
Copy link
Contributor

dcoutts commented May 30, 2013

Ok, so originally this design was deliberate, and similarly the lack of support for recursive directory globs (the goal was to avoid accidentally including things). But it seems like it's just too annoying so I'm happy to relent on both points.

As for whether it needs a backwards compat thing, that's a bit tricky. In principle we could check against existing packages to see if the meaning for any of them would change. If we can't be bothered to do that (and fair enough!) then the safe thing to do would be for the different behaviour to be conditional on the cabal-version.

@tibbe
Copy link
Member

tibbe commented Aug 31, 2013

@dcoutts I think this is blocked on you.

@tibbe
Copy link
Member

tibbe commented Dec 19, 2013

@dcoutts Can you please take a look?

@tibbe
Copy link
Member

tibbe commented Apr 7, 2014

Is this subsumed by #1344 or are they orthogonal?

@dcoutts
Copy link
Contributor

dcoutts commented Jun 21, 2014

Ok so in principle I'm fine with this so long as we can handle backwards compat properly. The concern is that this does change the behaviour of existing syntax so that it includes more than it did before. Though at least it's only changing at the point where you do sdist, not for builds of existing packages. So perhaps the cases where it will include things unexpectedly is so small that we can ignore it?

I think I'm inclined to let it go without having the behaviour be dependent on the version in the .cabal file. What do other people think?

@BardurArantsson
Copy link
Collaborator

If you're really concerned, you could issue a warning to stderr if the globs include more than they would have in previous versions? (Subject to a cabal version check, of course.)

(I personally don't think it's necessary, but sometimes paranoia pays off in SW development.)

EDIT: Of course an enthusiastic +1 from me, either way! :)

@hdgarrood
Copy link
Contributor Author

Is there a disadvantage to requiring a minimum Cabal-version? It seems, by not doing so, we might end up with a situation where two people working on the same package create different source distributions because one person has a version of Cabal which includes these changes, and the other doesn't. That's probably not what we want.

Also might it be better to continue this in #1975?

@tibbe
Copy link
Member

tibbe commented Jun 30, 2014

@hdgarrood requiring a Cabal-version constraint seems right the right thing to do if older Cabal versions will do the wrong thing interpreting the .cabal file with the new feature/syntax.

@dcoutts
Copy link
Contributor

dcoutts commented Mar 3, 2015

Hmm, this is still open but the later one #1975 was closed. I don't want to loose track of this improved globbing, it'd be useful. @hdgarrood any status update? If you don't have time anymore is this something you could hand over to someone else?

@hdgarrood
Copy link
Contributor Author

Sorry, I don't quite remember what happened here, but I don't think I have time to pick this up at the moment. I'd be more than happy to hand over.

@hdgarrood
Copy link
Contributor Author

Closing in favour of #2522

@hdgarrood hdgarrood closed this Apr 4, 2015
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.

5 participants