gtristan edited a comment on pull request #1609: URL: https://github.com/apache/buildstream/pull/1609#issuecomment-1066425803
> I find it a little hard to review, it would be nice to split into smaller PRs for review. I'd rather keep this in one PR as it's all related to the Directory API cleanup, splitting this up also generates extra considerations when updating moving parts, note that I already have https://gitlab.com/BuildStream/bst-plugins-experimental/-/merge_requests/166 lined up for this. I had considered trying to reduce the number of commits (which would be quite difficult short of squashing it all into one commit) but I would like to keep them all in history, every commit here passes it's own tests and tells a full story of how things were changed here which is nice to keep. [...] > I have a couple of comments on these: > > * storage/directory.py: Remove `can_link` parameter from Directory.import_files() > Even though it is currently unused, there is potential to have a similar option that uses the `move_files` hint (by passing `--capture-allow-file-moves` to `buildbox-casd`). Can be done later though. Sure I'll consider this unrelated, in any case it's highly unlikely that we would want to expose the abstract plugin API to such low level implementation details, given that the public API can never again be changed. > * storage/directory.py: Make Directory.export_files() an internal function > If we want to go for source.py: Split up staging functions into separate codepaths. #1607 (comment), > we'll need to keep this public. Again, this can be made public later if needed (even if it's not at 2.0). Why ? `Directory.export_files()` is only ever used by the core when *exporting* files in a virtual directory to the local filesystem, when e.g. checking out artifacts or sources, etc. `Directory.import_files()` of course needs to stay public. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
