Fix #34 -- Don't remove files with a hidden component

[ralsina]

This may not be a perfect fix but at least it makes the behaviour more predictable.

Without this, what files get baked into the binary depends on the path where you are building the software.

Specifically, when packaging for Arch Linux, packages are built inside ~/.cache which meant no files were ever accepted.

[straight-shoota]

I believe it would be better to restrict this PR to the relevant change in loader.cr.
Lint and formatter updates could go into a separate one.

[straight-shoota]

issue: What's happening with this file?

[ralsina]

I believe it would be better to restrict this PR to the relevant change in loader.cr. Lint and formatter updates could go into a separate one.

Done, removed that from here.

[ralsina]

Is there any way to get this merged? This is a popular shard and this is a real bug

[straight-shoota]

ping @schovi

[zw963]

It’s seem like just not get hidden file/folder baked into binary, this behavior is expected, those codes were added intentionally, to avoid the user added hidden user data to the binary accidentally, i consider it is not a bug.

[straight-shoota]

@zw963 This is a very limiting design joice. The user should decide which files they want to bake, and there's no good reason to categorially exclude path components that start with a dot. Especially considering that the hidden file semantics are just a convention on POSIX systems. On Windows for example path components starting with a dot are not considered hidden.

[ralsina]

And by not making this optional it means what you get in the baked binary depends on what folder you build it on. In Arch Linux, for example, source-based packages are built inside .cache which means you get nothing in the binary

…

On Thu, Sep 19, 2024, 4:59 AM Johannes Müller ***@***.***> wrote: @zw963 <https://github.com/zw963> This is a very limiting design joice. The user should decide which files they want to bake, and there's no good reason to categorially exclude path components that start with a dot. Especially considering that the hidden file semantics are just a convention on POSIX systems. On Windows for example path components starting with a dot are not considered hidden. — Reply to this email directly, view it on GitHub <#50 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAAMK5NTMKC2YKIQO2ZJC3ZXJ75LAVCNFSM6AAAAABNCZ6BN6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGNRQGI3DCNBVGM> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[zw963]

In Arch Linux, for example, source-based packages are built inside .cache which means you get nothing in the binary

Why would you add .cache into the binary, i am understand correct, what you means is ~/.cache in Arch Linux, right?

To be honest, I can't really think of a scenario where you would need to add dot file to binary, even on windows.

[ralsina]

In Arch Linux, for example, source-based packages are built inside .cache which means you get nothing in the binary

Why would you add .cache into the binary, i am understand correct, what you means is ~/.cache in Arch Linux, right?

To be honest, I can't really think of a scenario where you would need to add dot file to binary, even on windows.

Looks like the bug description is not clear enough.

It's not just that you can't add foo/.bar into the binary. You can't add .foo/bar either.

Further, if you want to add foo/bar but you are building in /.quux making the full path /.quux/foo/bar it will not be added to the binary.

This means the result of baking a directory into the binary depend not only on the relative path of the file you want to put in the binary but ON THE PATH WHERE THE CODE IS LOCATED.

I am not adding .cache into the binary. The tools to build binaries from source build them inside .cache

For example, pikaur would use ~/.cache/pikaur/pkg/foo to build the package foo
Since having any component in the path start with "." prevents a file from being baked, that meant NOTHING gets into the binary. Not a single file.