forked from lsst/daf_butler
-
Notifications
You must be signed in to change notification settings - Fork 0
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Hardcoded Butler.get from S3 storage for simplest of Datasets with no - rebased to include newest changes to daf_butler (namely, ButlerURI) - removed parsePathToUriElements, S3Location and S3LocationFactory, and replaced all path handling with ButlerURI and its test cases. - added transaction checks back into S3Datastore. Unsure on proper usage. - added more path manipulation methods/properties to LocationFactory and Location. * bucketName returns the name of the bucket in the Location/ LocationFactory * Location has a pathInBucket property that will convert posix style paths to S3 protocol style paths. The main difference is with respect to leading and trailing separators. S3 interprets `/path/`, `/path`, `path/` and `path` keys differently, even though some of them are equivalent on a POSIX compliant system. So what `/path/to/file.ext` would be on a POSIX system, on S3 it would read `path/to/file.ext` and the bucket is referenced separately with boto3. - For saving Config as file, moved all the URI handling logic into Config and out of Butler makeRepo. The only logic there is root directory creation. * The call to save config as a file at the butler root directory is now done through dumpToUri which then resolves the appropriate backend method to call. - Improved(?) on the proposed scheme for checking if we are dealing with a file or a directory in absence of the trailing path separator. * Noted some differences between the requested generality of code in the review for writing to files and inits of config classes. For inits it seems as if there's an 2+ year old commit limiting the Config files to `yaml` type files only. However, the review implied that `dumpToFile` on Config class should be file format independent. Then, for `dumpTo*` methods, to check whether we have a dir or a file I only inspect whether the path ends on a 'something.something' style. However, since I can count on files having to be `yaml` type and having `yaml` extensions in inits I use a simplified logic to determine if we have a dir or file. It is possible to generalize inits to other filetypes, as long as they have an extension added to them. * I assume we do not want to force users to be mindfull of trailing separators. - Now raising errors on unrecognized schemes on all `if scheme ==` patterns. - Closed the StreamIO in Config.dumpToFile - fixed up the Formatters to return bytes instead of strings. The fromBytes methods now expect bytes as well. JSON and YAML were main culprints. Fixed the docs for them. At this point I am confident I just overwrite the fixes when rewinding changes on rebase by accident because I have done that before, twice. - Added a different way to check if files exist, cheaper but can be slower. From boto/botocore#1248 it is my understanding that this should not be an issue anymore. But the newer boto3 versions are slow to hit package managers.
- Loading branch information
1 parent
fcc8677
commit 3dcf93a
Showing
16 changed files
with
448 additions
and
441 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.