Skip to content

Ignore .DS_Store and ._AppleDouble files when deciding whether to hoist tarball contents up a directory #4869

Open

Description

Checklist

  • I added a descriptive title
  • I searched open requests and couldn't find a duplicate

What is the idea?

When unpacking a tarball, conda-build can move the contents from a single subdirectory to the working directory:

If an extracted archive contains only 1 folder at its top level, its contents will be moved 1 level up, so that the extracted package contents sit in the root of the work folder.

See hoist_single_extracted_folder() and its invocation. Most well-made source tarballs do indeed contain only one top-level item, so this hoisting is typically used.

bioconda/bioconda-recipes#40722 was a recent update due to a new upstream release of the bedtools program. Unfortunately (unlike previous bedtools release tarballs) this upstream tarball contained .DS_Store files sprinkled across its directories, including at the top-level:

.DS_Store
bedtools2/
bedtools2/.DS_Store
bedtools2/Makefile
…etc…

Hence the hoisting was not done, leading to a build failure as the Makefile was not in the working directory as build.sh expected.

bioconda/bioconda-recipes#40802 is another attempt at updating to a new release of the same project. This time the upstream tarball contained ._foo AppleDouble files sprinkled throughout:

._bedtools2
bedtools2/
bedtools2/._Makefile
bedtools2/Makefile
…etc…

Hence once again the hoisting was not done, leading to a similar build failure.

Ideally upstream source tarballs would be generated without any of these spurious files, and bioconda will suggest to this upstream that they regenerate their latest release again.

However, it would also be ideal if the decision about hoisting ignored these trivial files.

Specifically it should ignore a top-level .DS_Store and a top-level ._foo (where foo also exists in the top-level) when counting whether the top-level directory contains only one item. (Probably it should delete them before counting, or at least delete them before moving the subdirectory contents up — to avoid potential collisions with subdirectory contents with the same name.)

Why is this needed?

No response

What should happen?

No response

Additional Context

No response

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Assignees

No one assigned

    Labels

    source::communitycatch-all for issues filed by community membersstale::recovered[bot] recovered after being marked as staletype::featurerequest for a new feature or capability

    Type

    No type

    Projects

    • Status

      🆕 New

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions