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

V0.10.x fix oras deployed code #754

Open
wants to merge 45 commits into
base: v0.10.x
Choose a base branch
from

Conversation

isc-shuliu
Copy link
Collaborator

@isc-shuliu isc-shuliu commented Mar 5, 2025

With this PR, deployed items are bundled into a %StudioProject for installing and uninstalling.

This PR also makes ORAS registries compatible with deployed items.

@isc-shuliu isc-shuliu marked this pull request as ready for review March 10, 2025 14:30
Copy link
Collaborator

@isc-kiyer isc-kiyer left a comment

Choose a reason for hiding this comment

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

@isc-shuliu Looks good but a few comments and action items. Also, general q: for listing modules in a repo + being able to install them, what is the defined behavior? I can think of the following cases:

  • Module exists in non-deployed mode: in this case, no special handling since it can be installed on any system
  • Module exists in deployed mode for version v1 and v2 and user is on v1 or v2: I think list-modules should display the versions for each platform available in list-modules but when the user tries to install, it picks the version they are on and installs the module. Perhaps could grey out or have an additional flag to list modules that are available in the repo but not installable on the current platform? By default I agree a user shouldn't be able to see module versions built for other platforms.
  • Module exists in deployed mode for version v1 and v2 and user is on v3: based on the above, a user would fail to install the module but would be worthwhile them getting a better error message indicating the module exists in the repo but is incompatible with their platform version and offering them a command to view all platform versions available a module (some variation of list-modules)

Copy link
Contributor

@isc-tleavitt isc-tleavitt left a comment

Choose a reason for hiding this comment

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

@isc-shuliu I have a few comments too; thank you for your work on this!

I do think it would be worth looking into PlatformVersion vs. PlatformVersions a bit more to see if we should just be using one of them.

@isc-shuliu
Copy link
Collaborator Author

@isc-shuliu Looks good but a few comments and action items. Also, general q: for listing modules in a repo + being able to install them, what is the defined behavior? I can think of the following cases:

  • Module exists in non-deployed mode: in this case, no special handling since it can be installed on any system
  • Module exists in deployed mode for version v1 and v2 and user is on v1 or v2: I think list-modules should display the versions for each platform available in list-modules but when the user tries to install, it picks the version they are on and installs the module. Perhaps could grey out or have an additional flag to list modules that are available in the repo but not installable on the current platform? By default I agree a user shouldn't be able to see module versions built for other platforms.
  • Module exists in deployed mode for version v1 and v2 and user is on v3: based on the above, a user would fail to install the module but would be worthwhile them getting a better error message indicating the module exists in the repo but is incompatible with their platform version and offering them a command to view all platform versions available a module (some variation of list-modules)

Opened a separate issue for this. For now, list-modules will list the latest package version regardless of platform version compatibility. When installing, we default to the latest package version and verify platform compatibility. Users can optionally install another version.

Set sorter(+semver.Major, +semver.Minor, +semver.Patch, " "_semver.Prerelease, " "_semver.Build) = version
}

Set major = ""
Copy link
Contributor

Choose a reason for hiding this comment

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

This is a great use case for $query but don't need to do that right now.

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.

HS needs IPM to correctly support deployed code in published packages
3 participants