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

[doc] Document how to do build.dart that uses packages from a local native package manager #189

Open
Tracked by #882
dcharkes opened this issue Nov 6, 2023 · 2 comments

Comments

@dcharkes
Copy link
Collaborator

dcharkes commented Nov 6, 2023

Probably with an example.

Related:

@mkustermann Do you want to supply what you did as a PR? or as a paste so when addressing this issue we can use it?

@mkustermann
Copy link
Member

mkustermann commented Nov 9, 2023

@mkustermann Do you want to supply what you did as a PR? or as a paste so when addressing this issue we can use it?

We'd probably want to think a bit more how we should do it: Possibly provide a shared helper package with logic for all operating systems (where needed). Also the build.dart script I wrote is specifically for homebrew, but it should be more general: It should find transitive shared libraries necessary, then only bundle those that aren't system-installed (instead of special casing the .homebrew directory, which may also be different for different users).

@dcharkes
Copy link
Collaborator Author

The build hook should probably branch on host OS and then try which package managers are available on PATH.

For package managers that are isolated, we can invoke the package manager right away and give it the output directory as the install location. (I'm thinking Gradle.)

For package managers that are used in a non-isolated way, brew, apt-get, Chocolatey, the build hook should not automatically install the packages but fail with stderr detailing that some package needs to be installed? (Automatically installing packages could break the users system by automatically uninstalling some incompatible packages. Moreover, one might need sudo rights to install something.)

The way that this might be structured is kind of similar to how package:native_toolchain_c tries to discover C compilers. So it seems reasonable to me that we should have a shared helper package indeed. package:native_package_manager?

(We could also consider reusing the Tool and ToolInstance abstractions #856. For recognizing tool versions and specifying constraints and alternatives.)

I'm not sure that this is needed for v1.0, I don't believe this will influence the protocol, let's bump it it after v1.0.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Status: No status
Development

No branches or pull requests

2 participants