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

Provide TARGETPATH normalizing convenience interface #1019

Closed
lukpueh opened this issue Apr 8, 2020 · 2 comments
Closed

Provide TARGETPATH normalizing convenience interface #1019

lukpueh opened this issue Apr 8, 2020 · 2 comments

Comments

@lukpueh
Copy link
Member

lukpueh commented Apr 8, 2020

Description of issue or feature request:
#1008 removes ambiguity in interfaces that take TARGETPATH arguments, by only accepting paths and path patterns that use "/" as directory separator and don't start with "/", as recommended in the specification (see #1018 for even stricter vetting of these arguments).

To provide a friendly user interface we should add normalizing functionality that transforms paths as returned by os.listdir, os.walk, repository_tool.Repository.get_filepaths_in_directory, etc... into a format that is accepted by methods that take TARGETPATHs.

Normalizing includes

  • strip targets directory prefix from absolute paths
  • convert Windows-style dir separators "" to Unix-style separators "/"
  • maybe perform os.path.normpath-like normalization, like collapsing redundant separators and up-level references

#957 has some discussions about least-suprise in TARGETPATH, e.g. what do do if an absolute path does not have the targets directory as prefix, or a relative path is passed, etc...

I envision an interface that may be used like this:

target_role.add_targets(normalize_target_paths(get_filepaths_in_directory(dir_path)))

or the with the latter two combined

target_role.add_targets(get_normalized_paths_in_directory(dir_path)))
@jku
Copy link
Member

jku commented Feb 16, 2022

I'm not closing this directly, maybe there is something here... However, current implementation does try to consider target paths as URL fragments, that may or may not map to a local path

@lukpueh
Copy link
Member Author

lukpueh commented Mar 17, 2022

The add_target-like interface of the new Metadata API requires callers to be explicit about the target_file_path as it appears in the targets metadata, and the the local path, used to determine hashes and length of the target file to be added:

python-tuf/tuf/api/metadata.py

Lines 1545 to 1556 in 8ac7167

def from_file(
cls,
target_file_path: str,
local_path: str,
hash_algorithms: Optional[List[str]] = None,
) -> "TargetFile":
"""Creates ``TargetFile`` object from a file.
Args:
target_file_path: URL path to a target file, relative to a base
targets URL.
local_path: Local path to target file content.

To keep the Metadata API minimal, I suggest to implement the requested convenience interface in a future repository tool. Since we don't have a roadmap for that yet, I'll close this issue and add a comment/reference in #1136.

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

No branches or pull requests

3 participants