You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
optionally fix the path by moving files up one directory.
remove downloaded path.
Yes, the complexity of it all is perplexing. At least for my little chimp brain 🐒
The following issues currently exist:
If the IPFS hash references a file, the current implementation will fail.
Otherwise, the directory is <ipfs_hash>/<dir_name>/.... That is, content of the IPFS hash is a directory, which contains a directory itself that bares a name. It is currently not clear whether or not a directory can be empty.
This edge case is not covered.
Let us assume it is not allowed to be. Thus, some number of files exists, which also bare a name.
if we dofix_path, we move the files up one directory, that is <ipfs_hash>/<dir_name>/... -> /<dir_name>/.... However, this abrogates the logic above where we check whether <target_dir>/<ipfs_hash> exists to assert whether or not the downloaded files already exist.
if we do notfix_path (which we presumably always do), then we delete the download, as we never moved the downloaded_path to target_dir, nullifying our efforts.
if we dofix_path, and if the downloaded directory contains nested directories, these are not copied or moved along with the file content in the directory.
foreach_fileinPath(downloaded_path).iterdir(): # grabs all files
shutil.move(str(each_file), target_dir)
Proposal:
In case of a single file, the filename is considered metadata and not associated with the IPFS hash or file content, in case a file the IPFS download retrieves a file we may return immediately. To my knowledge there exists no way to retrieve the original file name, though this would probably be useful. Please inform me if you know of a way to associate the original filename to the file.
If the downloaded directory is empty, let us raise a violent error.
The check to see if the downloaded file already exists was explained as "common practice". Let us annihilate it 🙏. The ipfshttpclient.Client(...).get(...) method has no issue overwriting exiting content either. If your local is different, your local is wrong. If we move files, we can deal with files already existing in a given location then.
Download to a temporary directory and copy the (arbitrarily) nested content to the target directory.
Let us remove the package_path defining logic entirely. It is used in the following location, where additional logic resides that deals with path modification 🙈. Other places where it is invoked do not use the return value
I'm opening an issue to clarify the issues with
IPFSTool.download
. The method has too many responsibilities.open-aea/plugins/aea-cli-ipfs/aea_cli_ipfs/ipfs_utils.py
Lines 309 to 370 in c607317
Effectively it just wraps
ipfshttpclient.Client(...).get(...)
.open-aea/plugins/aea-cli-ipfs/aea_cli_ipfs/ipfs_utils.py
Line 337 in c607317
What it actually does is:
Yes, the complexity of it all is perplexing. At least for my little chimp brain 🐒
The following issues currently exist:
<ipfs_hash>/<dir_name>/...
. That is, content of the IPFS hash is a directory, which contains a directory itself that bares a name. It is currently not clear whether or not a directory can be empty.Let us assume it is not allowed to be. Thus, some number of files exists, which also bare a name.
fix_path
, we move the files up one directory, that is<ipfs_hash>/<dir_name>/...
->/<dir_name>/...
. However, this abrogates the logic above where we check whether<target_dir>/<ipfs_hash>
exists to assert whether or not the downloaded files already exist.fix_path
(which we presumably always do), then we delete the download, as we never moved thedownloaded_path
totarget_dir
, nullifying our efforts.open-aea/plugins/aea-cli-ipfs/aea_cli_ipfs/ipfs_utils.py
Lines 368 to 369 in c607317
fix_path
, and if the downloaded directory contains nested directories, these are not copied or moved along with the file content in the directory.open-aea/plugins/aea-cli-ipfs/aea_cli_ipfs/ipfs_utils.py
Lines 361 to 362 in c607317
Proposal:
ipfshttpclient.Client(...).get(...)
method has no issue overwriting exiting content either. If your local is different, your local is wrong. If we move files, we can deal with files already existing in a given location then.package_path
defining logic entirely. It is used in the following location, where additional logic resides that deals with path modification 🙈. Other places where it is invoked do not use the return valueopen-aea/aea/cli/fetch.py
Lines 147 to 155 in beadc9f
The text was updated successfully, but these errors were encountered: