Open amitschang opened 1 year ago
Thanks for submitting this @amitschang! I'm able to replicate for the local-file-system block.
Thanks! For the local file system case at least, it seems that perhaps at https://github.com/PrefectHQ/prefect/blob/f5e1b10ffa0183f330356697fcaf17a8b7a63c0e/src/prefect/filesystems.py#L132-L135, the path needs to be added to the base, something like:
if from_path is None:
from_path = Path(self.basepath).expanduser().resolve()
else:
from_path = Path(self.basepath).joinpath(from_path).expanduser().resolve()
or so
Relative path manipulation in deployments should be fully resolved with the new work on projects (will be released in beta with 2.9.1 tomorrow).
@amitschang I'm curious if our beta setup for projects would help make this easier to debug and manage; you can check out the initial documentation directly in GitHub here.
In this setup, the root of your project directory is always the working directory for your deployment runs. Once the release is out you can experiment with this using prefect project init --recipe local
which I believe will capture your setup and allow you to customize it further.
I have the exactly same issue with S3 block
First check
Bug summary
When building a deployment setting path using either the
--path
argument or-sb {type}/{name}/{path}
style the upload of files works but flow run fails in the agent with something likeThis is the case for both s3 and a local-file-system block (which is accessible on the agent system). These fail in seemingly subtly different ways, for example the above is for s3, but for local what is not found appears to be a directory
The local-file-system case is fixed by modifying the
path
field of the deployment manifest (below the "### DO NOT EDIT BELOW THIS LINE" - oh no!) to the absolute path of the storage block, for example my local storage block has /prefect-storage as the basepath, so I set path to /prefect-storage/subdir and the flow will download and run.The same does not work for s3, I have not found a workaround for that. I should note the s3 base is
s3://{bucket}/{basepath}
and not directly under the bucket, however deploying a flow works as expected without the extra path argument.Appologies if these two are not the same issue, the traces are different but same user-experience, and it is possible the cause is the same, for example the logic for constructing the path could be flawed in the same way and handled differently by the different filesystems.
Reproduction
And deployment created using:
And for s3:
Additional context
No response