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

Incorrect bootstrap filename #247

Closed
cjntaylor opened this issue Dec 23, 2023 · 3 comments · Fixed by #248
Closed

Incorrect bootstrap filename #247

cjntaylor opened this issue Dec 23, 2023 · 3 comments · Fixed by #248

Comments

@cjntaylor
Copy link
Contributor

When run from within a zip file (such as by directly importing the shiv wheel or within a traditional zipapp), the bootstrap files are stored with temporary file names (From src/shiv/builder.py#L160-L167):

write_to_zipapp(
    archive,
    str(bootstrap_target / path.name),
    data,
    zipinfo_datetime,
    compression,
    stat=path.stat(),
)

str(bootstrap_target / path.name) won't work when embedded - path points to a temporarily extracted temporary file, producing archive names like this:

1980-01-01 06:00:00 .....         8977         3275  _bootstrap/tmp3dxelv3u__init__.py
1980-01-01 06:00:00 .....         2878          945  _bootstrap/tmpxt4291z2environment.py
1980-01-01 06:00:00 .....         2063          716  _bootstrap/tmp1lkt9o0xfilelock.py
1980-01-01 06:00:00 .....         1762          725  _bootstrap/tmprndqhn00interpreter.py

Is there some reason this isn't just str(bootstrap_target / bootstrap_file)? Making this simple change seems to work correctly in all cases I can test. PR incoming.

cjntaylor added a commit to cjntaylor/shiv that referenced this issue Dec 23, 2023
cjntaylor added a commit to cjntaylor/shiv that referenced this issue Dec 23, 2023
cjntaylor added a commit to cjntaylor/shiv that referenced this issue Feb 22, 2024
@cjntaylor
Copy link
Contributor Author

I'm normally not one to do this, but, just a quick *bump* as I've made an alteration to the PR to adjust to the most recent release, along with an explanation as to why I think this is important.

I'd be happy with a wontfix and this issue being closed. At least then I'm not in limbo of knowing if I need to maintain my own fork indefinitely or not.

@lorencarvalho
Copy link
Contributor

I'm normally not one to do this, but, just a quick bump as I've made an alteration to the PR to adjust to the most recent release, along with an explanation as to why I think this is important.

I'd be happy with a wontfix and this issue being closed. At least then I'm not in limbo of knowing if I need to maintain my own fork indefinitely or not.

So sorry for my absence on this issue & the associated PR! Ever since we started using Github internally I feel like I've not been keeping up with projects associated with my personal user, not an excuse though. I appreciate your patience!

@cjntaylor
Copy link
Contributor Author

No worries! I know that everyone is busy and it takes time to sort these things out. I appreciate the merge; I want to promote shiv's usage but that's a bit of a hard sell when I have to reference my git module as a dependency, so I'm glad that's settled.

Thanks for your hard work!

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 a pull request may close this issue.

2 participants