Initial Metadata implementation #2
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This implementation uses the same interface for V2 and CNB. A top level Metadata object is a loose wrapper around a low level metadata store that responds to get/set/fetch. I do need to figure out a migration strategy to migrate from existing heroku-buildpack-ruby metadata to this scheme, but that can come later. As values are set on the metadata stores they're written to disk right away so we don't have to worry about remembering to write to disk when we're done. A layer is currently represented as 3 things: - env - config - metadata (store.toml) Currently EnvProxy handles writing the env and the config. With the addition of this store, we've got a fairly comprehensive view for a layer. It's a little odd that the EnvProxy knows about config. I might want to change that in the future. But for now it's probably fine. There are some possible safety concerns. I'm not sure what happens if we write to a `store.toml` that is not configured. (build/launch/cache). We might need to add some guard statements like how EnvProxy will validate a layer before letting you write an env var to it. I explicitly wanted a non-hash-like interface for this metadata so that it would be crystal clear that a custom object is being interacted with. Currently nothing in the codebase is _using_ the metadata store , which is a bit odd for me. From a process perspective I usually only implement when I'm also using the interface. But I'm very satisfied with the current implementation.
schneems
force-pushed
the
schneems/metadata
branch
from
2ea8ed0 to
4761b95
Compare
schneems
added a commit
that referenced
this pull request
Dec 12, 2024
```
error: macros that expand to items must be delimited with braces or followed by a semicolon
--> buildpacks/ruby/src/layers/bundle_install_layer.rs:120:1
|
120 | / try_migrate_deserializer_chain!(
121 | | chain: [MetadataV1, MetadataV2, MetadataV3],
122 | | error: MetadataMigrateError,
123 | | deserializer: toml::Deserializer::new,
124 | | );
| |_^
|
= note: this error originates in the macro `$crate::try_migrate_link` which comes from the expansion of the macro `try_migrate_deserializer_chain` (in Nightly builds, run with -Z macro-backtrace for more info)
```
Or with nightly:
```
$ RUSTFLAGS="-Zmacro-backtrace" cargo build
error: macros that expand to items must be delimited with braces or followed by a semicolon
--> /Users/rschneeman/.cargo/registry/src/index.crates.io-6f17d22bba15001f/magic_migrate-0.2.0/src/lib.rs:437:34
|
419 | macro_rules! try_migrate_link {
| ----------------------------- in this expansion of `$crate::try_migrate_link!` (#3)
...
437 | $crate::try_migrate_link!($b, $($rest),*)
| ^^^^^^^^^^^^^^^^
...
714 | macro_rules! try_migrate_deserializer_chain {
| -------------------------------------------
| |
| in this expansion of `try_migrate_deserializer_chain!` (#1)
| in this expansion of `$crate::try_migrate_deserializer_chain!` (#2)
...
737 | $crate::try_migrate_link!($a, $($rest),+);
| ----------------------------------------- in this macro invocation (#3)
...
764 | $crate::try_migrate_deserializer_chain!(error: $err, deserializer: $deser, chain: [$a, $($rest),+]);
| --------------------------------------------------------------------------------------------------- in this macro invocation (#2)
|
::: buildpacks/ruby/src/layers/bundle_install_layer.rs:120:1
|
120 | / try_migrate_deserializer_chain!(
121 | | chain: [MetadataV1, MetadataV2, MetadataV3],
122 | | error: MetadataMigrateError,
123 | | deserializer: toml::Deserializer::new,
124 | | );
| |_- in this macro invocation (#1)
error: could not compile `heroku-ruby-buildpack` (bin "heroku-ruby-buildpack") due to 1 previous error
```
I'm committing it because I want to figure out how to write a test case for this failure mode in the `magic_migrate` library.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This implementation uses the same interface for V2 and CNB. A top level Metadata object is a loose wrapper around a low level metadata store that responds to get/set/fetch.
I do need to figure out a migration strategy to migrate from existing heroku-buildpack-ruby metadata to this scheme, but that can come later.
As values are set on the metadata stores they're written to disk right away so we don't have to worry about remembering to write to disk when we're done.
A layer is currently represented as 3 things:
Currently, EnvProxy handles writing the env and the config. With the addition of this store, we've got a fairly comprehensive view for a layer. It's a little odd that the EnvProxy knows about config. I might want to change that in the future. But for now it's probably fine.
There are some possible safety concerns. I'm not sure what happens if we write to a
store.tomlthat is not configured. (build/launch/cache). We might need to add some guard statements like how EnvProxy will validate a layer before letting you write an env var to it.I explicitly wanted a non-hash-like interface for this metadata so that it would be crystal clear that a custom object is being interacted with. Currently nothing in the codebase is using the metadata store , which is a bit odd for me. From a process perspective I usually only implement when I'm also using the interface. But I'm very satisfied with the current implementation.