-
Notifications
You must be signed in to change notification settings - Fork 54
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Check the size of build_path
#653
Check the size of build_path
#653
Conversation
✅ Deploy Preview for kaleidoscopic-dango-0cf31d canceled.
|
@@ -190,15 +190,22 @@ def build_path(self, conda_store): | |||
""" | |||
store_directory = os.path.abspath(conda_store.store_directory) | |||
namespace = self.environment.namespace.name | |||
name = self.specification.name |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not used in build_directory
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How come? Not anymore? I thought it had the hash, timestamp and name? Or is that part of the 'build_key' thingy?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It was not used before this PR, just a mistake that I fixed since I was making changes here anyway.
This is the one used below, no name
here:
build_directory = Unicode(
"{store_directory}/{namespace}",
help="Template used to form the directory for storing conda environment builds. Available keys: store_directory, namespace, name. The default will put all built environments in the same namespace within the same directory.",
config=True,
)
I thought it had the hash, timestamp and name? Or is that part of the 'build_key' thingy?
Yes, it's in build_key
, which we append later:
def build_key(self):
...
return f"{self.specification.sha256}-{self.scheduled_on.strftime(datetime_format)}-{self.id}-{self.specification.name}"
TODO:
|
71dd8a5
to
e69c999
Compare
e69c999
to
291f12a
Compare
This extends the scope of try because an exception can be thrown in `append_to_logs`. For the same reason, `set_build_failed` is called first in except blocks. Fixes conda-incubator#654.
These tests check whether the status is set to FAILED when an exception occurs in a task.
26a441b
to
34ebf5b
Compare
This is an additional way to communicate information about the status of a build, which will be exposed to the user.
1ff7efe
to
34ac2dd
Compare
Companion PR for conda-incubator/conda-store#653
Companion PR on the UI side (see screenshot there): conda-incubator/conda-store-ui#332 |
# OSError: [Errno 36] File name too long | ||
255, | ||
# OSError: [Errno 36] File name too long | ||
256, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
These error messages the code used to throw before I moved build_path
to the start of the function in build_conda_environment
. Note how the messages here are different compared to tests/test_api.py
, this is correct since different backends are used.
) | ||
if size > 255: | ||
assert response.status_code == 500 | ||
return # error, nothing to do |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Note the change here compared to test_server.py
. Again, this is due to different backends being used for these.
In the UI this manifests as follows: I attempt to add an env with 256 'a's, click on the "Create" button in "Create Environment", but nothing is shown. The env is also not created. This is something I'll need to fix in the companion UI PR - the UI should show an error.
Companion PR for conda-incubator/conda-store#653
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good!
The main part of this PR is:
if len(str(res)) > 255:
raise BuildPathError("build_path too long: must be <= 255 characters")
I think we can afford to be more detailed here, but I don't know if that's the correct place. Maybe just codifying the error type with an identifier+number we can add some documentation on how to work around this issue?
@@ -15,6 +15,10 @@ def message(self): | |||
return self.args[0] | |||
|
|||
|
|||
class BuildPathError(CondaStoreError): |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm more used to having exceptions in an exceptions.py
module, but I guess there's a precedence to have them in utils.py
? Probably worth its own issue, not blocking here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, agree. But not changing it now. Added it next to the existing exception.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's add an issue to cover this later.
# conda prefix must be less or equal to 255 chars | ||
# https://github.com/conda-incubator/conda-store/issues/649 | ||
if len(str(res)) > 255: | ||
raise BuildPathError("build_path too long: must be <= 255 characters") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe we can afford to be more informative here and report which components are responsible for build_path
. What about:
f"'build_path' is too long ({len(str(build_path))}). Maximum allowed length is 255. See docs at xxx for more information.
This is also an opportunity to start codifying error numbers and have a reference online so folks can troubleshoot, à la https://flake8.pycqa.org/en/latest/user/error-codes.html. (worth its own issue).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That what I had originally, but I removed it. See here #653 (comment). As for codifying the errors: not adding that here either. There's no policy/format on this right now. Similarly, saying "see the docs" is not helpful. This also needs to be linked and done in a systematic way, otherwise links will point to nowhere over time. Not adding this also because there's no infra for this right now. Let's keep the PR self-contained, we can always change this later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's keep the PR self-contained, we can always change this later.
Works for me, but let's make sure there's an issue we can iterate on.
@@ -190,15 +190,22 @@ def build_path(self, conda_store): | |||
""" | |||
store_directory = os.path.abspath(conda_store.store_directory) | |||
namespace = self.environment.namespace.name | |||
name = self.specification.name |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How come? Not anymore? I thought it had the hash, timestamp and name? Or is that part of the 'build_key' thingy?
I initially printed the whole path and its size, too. But that'd be flaky on CI because different directories are used everywhere. It also seems like an implementation detail, which is not helpful unless you have admin rights. I'll just add documentation for now and we can improve later. |
Hey @jaimergp, thanks for your comments! I'm going to document the UPD: Added documentation. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The PR covers enough to have some protection against too long paths. The information conveyed could be more detailed, and less hardcoded. But that can be worked on in future PRs.
For example, I could imagine the UI receiving a JSON payload with the details of the error instead of a simple string. And then we decide what to do with the payload depending on the user role
At the same time, we've identified an opportunity to standardize error messages with error codes for easier (and more accurate) documentation.
These two improvements could help in future efforts like e.g. localization or theming.
Issues need to be created to cover these suggestions, but fwiw, this PR is good to go on my side.
@jaimergp is this ready for merge? if so then perhaps you and/or @nkaretnikov should open a follow-up issue with potential improvements or areas to explore and merge this straight away |
Fixes #649.