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

Since version 0.10.0 pure wildcard does not work in some cases #62

Closed
bzakdd opened this issue Sep 1, 2022 · 4 comments
Closed

Since version 0.10.0 pure wildcard does not work in some cases #62

bzakdd opened this issue Sep 1, 2022 · 4 comments

Comments

@bzakdd
Copy link

bzakdd commented Sep 1, 2022

Behavior of pattern "match everything" changed when upgrading from version 0.9.0 to 0.10.0:


Version 0.9.0

>>> import pathspec
>>> patterns = pathspec.PathSpec.from_lines(pathspec.patterns.GitWildMatchPattern, ["*"])
>>> 
>>> print(patterns.match_file('anydir/file.txt'))
True

Result is as expected


Version 0.10.0

>>> import pathspec
>>> patterns = pathspec.PathSpec.from_lines(pathspec.patterns.GitWildMatchPattern, ["*"])
>>> 
>>> print(patterns.match_file('anydir/file.txt'))
False

Result is wrong. * should match any file, but it doesn't match anydir/file.txt.


Discovered when checking case "match everything except for one directory":

patterns = pathspec.PathSpec.from_lines(pathspec.patterns.GitWildMatchPattern, ["*", "!product_dir/"])

On version 0.9.0 it correctly matches file outside of product_dir and doesn't match file inside:

>>> print(patterns.match_file('anydir/file.txt'))
True
>>> print(patterns.match_file('product_dir/file.txt'))
False

On version 0.10.0 it doesn't match in either case:

>>> print(patterns.match_file('anydir/file.txt'))
False
>>> print(patterns.match_file('product_dir/file.txt'))
False
@cpburnz
Copy link
Owner

cpburnz commented Sep 2, 2022

Hi @bzakdd, thanks for the bug report. This was a regression from fixing #19. This is now fixed and will be in the v0.10.1 release.

@cpburnz cpburnz closed this as completed Sep 2, 2022
@bzakdd
Copy link
Author

bzakdd commented Sep 2, 2022

@cpburnz Thank you!)

@ichard26
Copy link
Contributor

ichard26 commented Sep 5, 2022

Hi @cpburnz, looks like this has the potential to cause some serious usability problems for downstream users. Black just received a bug report (psf/black#3256) where Black is now reformatting virtual environments (!) named env with pathspec==0.10.0. This is because virtual environments (only those created by virtualenv, not venv) contain a .gitignore file that simply excludes everything.

$ virtualenv env
created virtual environment CPython3.8.5.final.0-64 in 2959ms
  creator CPython3Posix(dest=/home/ichard26/programming/oss/dir/env, clear=False, no_vcs_ignore=False, global=False)
  seeder FromAppData(download=False, pip=bundle, setuptools=bundle, wheel=bundle, via=copy, app_data_dir=/home/ichard26/.local/share/virtualenv)
    added seed packages: pip==22.2.2, setuptools==63.4.3, wheel==0.37.1
  activators BashActivator,CShellActivator,FishActivator,NushellActivator,PowerShellActivator,PythonActivator

$ cat env/.gitignore 
# created by virtualenv automatically
*

Black doesn't have env as part of its default excludes so our safeguard that usually prevents virtual environments from being reformatted is useless here. I know that naming virtual environments env isn't particularly common, but when it does happen, this issue can make Black unusable (since virtual environments can often have an insane amount of code to reformat). Yes it's easy to fix (put env in your --extend-exclude configuration), but it's better if this isn't necessary in the first place.

Would you be open to yanking pathspec 0.10.0 on PyPI? It will prevent most users from getting the broken version, but won't break people who are already locked on 0.10.0. It's a bit like a "strongly discouraged for use" marker but for pip 🙂 This post explains it well (see the "The whole release is bad" header).

Thanks in advance!

@cpburnz
Copy link
Owner

cpburnz commented Sep 5, 2022

@ichard26 I have no problem with pulling down v0.10.0 because it broke a very common pattern.

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

No branches or pull requests

3 participants