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

Revert "Fix empty folder missing problem when zip files. (#330)" #350

Merged
merged 1 commit into from
Jan 31, 2025

Conversation

joan38
Copy link
Contributor

@joan38 joan38 commented Jan 31, 2025

This reverts commit 90626df.
Fixes #349

I've spent some time trying to do a fix forward but I don't have much time on my hand.
Can we revert this in the meantime and @counter2015 can provide another PR for the empty folder issue?

@lihaoyi lihaoyi merged commit cf2e9a6 into com-lihaoyi:main Jan 31, 2025
7 of 8 checks passed
@joan38
Copy link
Contributor Author

joan38 commented Jan 31, 2025

@lihaoyi can you rerun the failing build?

@joan38 joan38 deleted the zip branch January 31, 2025 22:47
@joan38
Copy link
Contributor Author

joan38 commented Jan 31, 2025

Ah ok thanks 🙂

@lihaoyi
Copy link
Member

lihaoyi commented Jan 31, 2025

Tagged this as 0.11.4-M5, will propagate it to Mill once it's published

lihaoyi added a commit to com-lihaoyi/mill that referenced this pull request Feb 1, 2025
@counter2015
Copy link
Contributor

counter2015 commented Feb 4, 2025

@joan38 Thanks for report. I'm not sure whether I understand correctly. It seems the commit break the unwritten rules. But in my persion thinking, the newer one is more intuitive. The former version seems handle folder and file differently. Do you except that when user pass a folder to zip parameter, we should access inside it ?

Then I have a quesion here, if user want to keep the outer folder, how can we do that?
In first glance, I think we can pass the parent folder but exclude other content (it's not convenient).

The common zip command in linux support pass muti source include files and folders and keep the outside folder sources

For example

$ tree
.
├── run.scala
└── sources
    ├── file1.txt
    └── file2.txt


$ zip archieve.zip sources run.scala
  adding: sources/ (stored 0%)
  adding: run.scala (deflated 41%)

$ tree
.
├── archieve.zip
├── run.scala
└── sources
    ├── file1.txt
    └── file2.txt

I acknowledge that my previous PR may have introduced breaking changes due to oversights in the implementation. However, from my perspective, retaining directory structures during compression aligns more closely with user intuition. What's your opinion ? @lihaoyi

@joan38
Copy link
Contributor Author

joan38 commented Feb 4, 2025

@counter2015 The readme says:

This will create a new zip archive at dest containing file1.txt and everything inside sources.

But your point is fair and I thought about that too.

I'll give you an example taken from what broke downstream for a Mill plugin:

os.zip(dest / "docusaurus.zip", Seq(wd / "build"))

How would you implement this with your implementation?
My fix was:

os.zip(dest / "docusaurus.zip", os.list(wd / "build").map(os.zip.ZipSource.fromPath))

(BTW I think we need some conversions for Seq[Path] to Seq[ZipSource] to avoid .map(os.zip.ZipSource.fromPath))

Both are good to me but maybe we need a 0.12.0 version bump for such change? @lihaoyi WDYT?

Also I want to thank you for your contribution @counter2015, it's very much appreciated.

Thanks

@joan38
Copy link
Contributor Author

joan38 commented Feb 4, 2025

I just opened #352
Maybe with that we could make the change but not sure about the breaking aspect of it.

gamlerhart pushed a commit to gamlerhart/mill that referenced this pull request Feb 9, 2025
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.

zip is zipping up the source folder instead of its content
3 participants