Skip to content
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

Allow converting PDFv1 to PDFv2 in-memory only #1670

Merged
merged 1 commit into from
Oct 4, 2024

Conversation

sfc-gh-fcampbell
Copy link
Contributor

@sfc-gh-fcampbell sfc-gh-fcampbell commented Oct 4, 2024

Pre-review checklist

  • I've confirmed that instructions included in README.md are still correct after my changes in the codebase.
  • I've added or updated automated unit tests to verify correctness of my new code.
  • I've added or updated integration tests to verify correctness of my new code.
  • I've confirmed that my changes are working by executing CLI's commands manually on MacOS.
  • I've confirmed that my changes are working by executing CLI's commands manually on Windows.
  • I've confirmed that my changes are up-to-date with the target branch.
  • I've described my changes in the release notes.
  • I've described my changes in the section below.

Changes description

Extracted from #1667 to get separate CLI team codeowner review.

Allows converting a v1 definition to v2 only in-memory, without saving the resultant v2 definition to snowflake.yml. This will be used in a future decorator added in #1667 to allow v1 commands to operate natively on v2 entities by implicitly converting the definition.

Since the definition conversion process currently updates package script files in-place, we need a way to isolate those changes to a temp directory instead of touching the user's project directory. This is achieved by creating a tempdir to hold these conversions and by replacing the package script filenames in the project definition with absolute paths to those temp files, taking advantage of the (documented) fact that Path(...) / "/tmp/foo" ignores the first Path since the second is absolute, resulting in just Path("/tmp/foo").

Since the definition contents will never be emitted to disk to be loaded in the future, another thing we need to do is evaluate templates in the converted project definition immediately instead of returning a definition with tags in it.

In addition, since we're modifying the project definition in-memory, we also need to override the template context to be used for future template expansions in other files, so this ability was added to the CLI global context manager.

Comment on lines 56 to +59
# FIXME: this property only exists to help implement
# nativeapp_definition_v2_to_v1. Consider changing the way
# this calculation is provided to commands in order to remove
# this logic (then make project_definition a non-cloned @property)
# nativeapp_definition_v2_to_v1 and single_app_and_package.
# Consider changing the way this calculation is provided to commands
# in order to remove this logic (then make project_definition a non-cloned @property)
Copy link
Contributor Author

@sfc-gh-fcampbell sfc-gh-fcampbell Oct 4, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I know this is proliferating a self-proclaimed undesirable pattern, but I think it's worth it for the simplicity of the change. We'll have a better opportunity to fix this once this v1-to-v2 refactor is done.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ok

Comment on lines +113 to +114
if envs is not None:
data["env"] = envs
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

None isn't a valid value for env according to the pydantic model. When saving the converted PDF to disk, None is omitted but when converting in-memory, we need to omit it here.

@sfc-gh-fcampbell sfc-gh-fcampbell force-pushed the frank-in-memory-pdf-conversion branch 3 times, most recently from d51894d to 07bf2a7 Compare October 4, 2024 12:27
@sfc-gh-fcampbell sfc-gh-fcampbell changed the title Allow converting PDFv2 to PDFv2 in-memory only Allow converting PDFv1 to PDFv2 in-memory only Oct 4, 2024
@sfc-gh-fcampbell sfc-gh-fcampbell marked this pull request as ready for review October 4, 2024 12:59
@sfc-gh-fcampbell sfc-gh-fcampbell requested review from a team as code owners October 4, 2024 12:59
@sfc-gh-fcampbell sfc-gh-fcampbell merged commit 3537be5 into main Oct 4, 2024
21 checks passed
@sfc-gh-fcampbell sfc-gh-fcampbell deleted the frank-in-memory-pdf-conversion branch October 4, 2024 14:43
sfc-gh-sichen pushed a commit that referenced this pull request Oct 17, 2024
Allows converting a v1 definition to v2 only in-memory, without saving the resultant v2 definition to `snowflake.yml`. This will be used in a future decorator added in #1667 to allow v1 commands to operate natively on v2 entities by implicitly converting the definition.

Since the definition conversion process currently updates package script files in-place, we need a way to isolate those changes to a temp directory instead of touching the user's project directory. This is achieved by creating a tempdir to hold these conversions and by replacing the package script filenames in the project definition with absolute paths to those temp files, taking advantage of the (documented) fact that `Path(...) / "/tmp/foo"` ignores the first `Path` since the second is absolute, resulting in just `Path("/tmp/foo")`.

Since the definition contents will never be emitted to disk to be loaded in the future, another thing we need to do is evaluate templates in the converted project definition immediately instead of returning a definition with tags in it.

In addition, since we're modifying the project definition in-memory, we also need to override the template context to be used for future template expansions in other files, so this ability was added to the CLI global context manager.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants