-
Notifications
You must be signed in to change notification settings - Fork 12
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
Implement force_identicial_write
#260
Implement force_identicial_write
#260
Conversation
I've realized the best place to add docs is probably the However, it's hard to demonstrate the functionality without encountering the same issue as described in #258. Perhaps the solution is For now, I have used |
just wanted to say that I've seen this and will give it a closer look in the next |
I hope the conference went well! I think the test that's failing needs to change based on the new default behaviour, I'll take a look now. |
4c31b9b
to
c95ecea
Compare
It did! It's one of my favorites (not that I am biased or anything 😆)
++ I can kick off the full set of tests again in a moment here to pick up your new commits! |
Late comment, but some history here is that Posit Connect cannot delete the most recent pin. IIRC that is in place since |
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.
did some small update around the tests, but this looks good to me!
@@ -248,8 +250,16 @@ def _pin_store( | |||
|
|||
pin_name = self.path_to_pin(name) | |||
|
|||
# Pre-emptively fetch the most recent pin's meta if it exists - this is used | |||
# for the force_identical_write check | |||
abort_if_identical = not force_identical_write and self.pin_exists(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.
this may make writing pins slightly slower by making a call to the pin in self.pin_exists()
. I think it's right move here (and I don't see a significant slowdown in tests at all), but just noting it if other calls get added and things start to feel sluggish
To resolve #241.
I struggled for a while to realize that
prepare_pin_version
deletes the old pin viaversion_setup
for unversioned boards. To deal with this, I have pre-emptively retrieved the meta object before it is deleted, and then used that to compare the hash.I think part of the issue is perhaps that
version_setup
doesn't belong inpins/versions.py
- I am of the view that it is currently too decontextualized and would be better closer to the place where it is invoked, inprepare_pin_version
. A docstring would help too.It's worth noting that this is a breaking change - as a result some of the existing tests needed modifying to opt-in to the old behaviour.
I'm not sure whether the READMEs need any updates. I took a read but I think it would be distracting to detail this feature.