Mercurial > repos > shellac > sam_consensus_v3
diff env/lib/python3.9/site-packages/boto/file/README @ 0:4f3585e2f14b draft default tip
"planemo upload commit 60cee0fc7c0cda8592644e1aad72851dec82c959"
author | shellac |
---|---|
date | Mon, 22 Mar 2021 18:12:50 +0000 |
parents | |
children |
line wrap: on
line diff
--- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/env/lib/python3.9/site-packages/boto/file/README Mon Mar 22 18:12:50 2021 +0000 @@ -0,0 +1,49 @@ +Handling of file:// URIs: + +This directory contains code to map basic boto connection, bucket, and key +operations onto files in the local filesystem, in support of file:// +URI operations. + +Bucket storage operations cannot be mapped completely onto a file system +because of the different naming semantics in these types of systems: the +former have a flat name space of objects within each named bucket; the +latter have a hierarchical name space of files, and nothing corresponding to +the notion of a bucket. The mapping we selected was guided by the desire +to achieve meaningful semantics for a useful subset of operations that can +be implemented polymorphically across both types of systems. We considered +several possibilities for mapping path names to bucket + object name: + +1) bucket = the file system root or local directory (for absolute vs +relative file:// URIs, respectively) and object = remainder of path. +We discarded this choice because the get_all_keys() method doesn't make +sense under this approach: Enumerating all files under the root or current +directory could include more than the caller intended. For example, +StorageUri("file:///usr/bin/X11/vim").get_all_keys() would enumerate all +files in the file system. + +2) bucket is treated mostly as an anonymous placeholder, with the object +name holding the URI path (minus the "file://" part). Two sub-options, +for object enumeration (the get_all_keys() call): + a) disallow get_all_keys(). This isn't great, as then the caller must + know the URI type before deciding whether to make this call. + b) return the single key for which this "bucket" was defined. + Note that this option means the app cannot use this API for listing + contents of the file system. While that makes the API less generally + useful, it avoids the potentially dangerous/unintended consequences + noted in option (1) above. + +We selected 2b, resulting in a class hierarchy where StorageUri is an abstract +class, with FileStorageUri and BucketStorageUri subclasses. + +Some additional notes: + +BucketStorageUri and FileStorageUri each implement these methods: + - clone_replace_name() creates a same-type URI with a + different object name - which is useful for various enumeration cases + (e.g., implementing wildcarding in a command line utility). + - names_container() determines if the given URI names a container for + multiple objects/files - i.e., a bucket or directory. + - names_singleton() determines if the given URI names an individual object + or file. + - is_file_uri() and is_cloud_uri() determine if the given URI is a + FileStorageUri or BucketStorageUri, respectively