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

strip_root behaviour with pattern differs between tools.unzip and tools.untargz #14455

Open
scummos opened this issue Aug 9, 2023 · 3 comments · May be fixed by #17591
Open

strip_root behaviour with pattern differs between tools.unzip and tools.untargz #14455

scummos opened this issue Aug 9, 2023 · 3 comments · May be fixed by #17591
Assignees

Comments

@scummos
Copy link

scummos commented Aug 9, 2023

Environment details

Conan version 1.57.0

Steps to reproduce

Consider an archive with a structure like this

  • root_dir/a.txt
  • root_dir/b.txt

This is compressed once as .tar.gz and once as .zip. I would expect this command:

conans.tools.unzip("archive.XXX", pattern="a.txt", strip_root=True)

to extract a.txt. But this only happens for the .tar.gz archive. For the zip, I need to specify root_dir in the pattern.

Both behaviours can be argued for (though I'd say if I pass strip_root, I have expressed I do not care about the root directory, and do not want to pass its name in my pattern -- that's half the point of the option) but it should certainly be consistent.

Logs

No response

@memsharded memsharded self-assigned this Aug 9, 2023
@memsharded
Copy link
Member

Hi @scummos

Thanks for your comments.

It seems you are using the legacy from conans tools. These are no longer recommended and will not get any changes anymore. Please update to the new tools from conan.tools.files import xxxx. In that new scope the untargz is not exposed anymore, it is internal only, so unzip() should always be used.

@scummos
Copy link
Author

scummos commented Aug 9, 2023

Hi, ok, but is the behaviour actually fixed there? The problem is not with the untargz function signature, it is with the logic itself. Calling unzip for both archives has the same problem.

@memsharded
Copy link
Member

Hi, ok, but is the behaviour actually fixed there?

I don't know, it is possible that the issue is still happening there. But also new tools have fixed tons of issues, so it might be possible that it is fixed too. As legacy tools will not get the fixes anyway, the recommendation is to update to the new tools and report against those. Having a quick look to the new tools, it seems they are using the same fnmatch() expression for the pattern, both for unzip and untargz, so apparently this should behave the same, and this would need to be further investigated, once confirmed it keeps happening with the new tools. Many thanks!

@jusito jusito linked a pull request Jan 17, 2025 that will close this issue
5 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants