Add 'hooks' sections into pubspec.yaml.
Pub manager feature request. Add 'preget' and 'postget' sections into pubspec.yaml. This can be useful when installing the packages. Example.
#pubspec.yaml
name: my_lib
hooks:
preget:
- sh ./bin/my_pre_get_script.sh
postget:
- sh ./bin/my_post_get_script.sh
# my_pre_get_script.sh
#do something check before `pub get`
# my_post_get_script.sh
#do something init after `pub get`
We currently have build_runner and package:build, but pub run build_runner build does not automatically run after pub get.
I think it's deliberate that no hooks are exposed, so I'm curious what use-cases do people see for a mechanism like this? code-gen, what else?
This has come up a few times before, so it is probably worth going through the issue tracker and looking at all the comments in those issues. Thus far we had always decided not to do it though because of the potential risks to both security and the perceived speed of pub (which would now be arbitrarily slow based on the hooks your deps specified).
We've had requests in the past for hooks that apply when a package is fetched as a dependency. I don't recall if we've had this request which is to have hooks that apply when the package is the root.
This one could be handled easily by an external tool that wraps pub.
I'm very curious what types of work you'd like to be done before and after a pub get...
I would like to see this feature in progress. Here is my use case: I'm trying to build a package which needs some binary/tools to be installed in order to work. I can't ask the user to download these because every version of my package depends on a specific version of binary/tool. So I don't want user to do some prerequisite every time they update my package. I would like to grab the compatible binary/tool as part of my package via a script/code and the package installation will fail if it fails to get the required items.
@BugDiver, that's a more specific use-case though.
Note you might be able to do this with build_runner, users will still have to run a command, but at-least it's one that runs multiple kinds of code generation.
@jonasfj That's right My use case is quite specific, and It might be doable via build_runne but I still have t a strong feeling that we need the feature. There are various use cases for it depending on the type of package people are building. Most of the package managers provide this sort fo feature (pip, npm, cargo etc) so that the users do not have to do all the stuff.
Have you considered shipping these tools with your package itself? If they are really specific to each version that might be sensible, depending on their size.
Most of the package managers provide this sort fo feature (pip, npm, cargo etc) so that the users do not have to do all the stuff.
The problem of shipping compiled code that is used with dart:ffi is certainly a concern -- also not an easy fix. Maybe it something we fix with a manual step, such that users have to do pub run my_package:build before using the package, after pub get. Then my_package just contains a /executables/builld.dart script that builds the binary and stores it in .dart_tool/my_package/....
Once a decent build system emerges we can discuss integrating more.
If something has to be done before or after 'pub get'.But We cannot guarantee anyone to do with pub run build_runner build or some other coding.It is unnecessary and dangerous.I really want the 'hooks'.
It is unnecessary and dangerous.I really want the 'hooks'.
How is it dangerous? I would argue it is more dangerous to have arbitrary code executed on pub get.
I really want the 'hooks'.
Can you describe your specific use case? That will make it easier for us to triage our work here.
Can you describe your specific use case? That will make it easier for us to triage our work here.
If I want to define own git standard by using git hooks. How can I achieve this without other developer knowing.
If I want to define own git standard by using git hooks. How can I achieve this without other developer knowing.
I'm not sure exactly what that means. I don't think it is helpful for a downloaded package to mess with the end users git repo.
I think it would be very useful to have before and after pub get hooks.
@branflake2267 can you describe your use case in further detail. There might be work-arounds that work out better, or we might finally be convinced to do something like this...
I've encountered custom dependencies quite often in the enterprise environment because of locked down repositories. So I was hoping I could provide credentials to private packages in the shell script. Pub doesn't have any spec on using credentials to access a repo. npm private repositories is a good example of a spec that has a path to provide credentials. Maven is another example with ~/.m2/settings.xml spec. But most of all the private enterprise environments need flexibility in managing custom dependency configs, never are the environments ideal. Bigger the org, the more fractured it becomes. Overall, adding some flexibility in hooking in on running seems quite common practice in the other dependency manifests out there.
One more note, I was thinking the script running, does present challenges, that said, I'd probably write my script in custom-script.dart so it's not OS dependent.
So I have two goals
- Provide private repo credentials to git or my private pub.
- Provide some flexibility in running a script to decrypt or set a license
@branflake2267 with this PR https://github.com/dart-lang/pub/pull/2654 you will have the possibility to provide a token for private repositories
We currently have build_runner and
package:build, butpub run build_runner builddoes not automatically run afterpub get.I think it's deliberate that no hooks are exposed, so I'm curious what use-cases do people see for a mechanism like this? code-gen, what else?
For example, when we use git hooks, actually we modify local .git file to add our cmd. For a team, you need to make sure that each member executes a script after cloning the project. However, this is very inconvenient and easy to forget, because even if you do not execute this command, you can compile the project. But if we increase the hooks function, for other members, they will use the pub get command to obtain dependencies as before, and unknowingly, they will access the git hook function.
When using husky to manage git hooks for Flutter an Dart projects, it's necessary to make sure developers have run dart run husky install locally. With hooks, this will be very convenient.
https://github.com/dart-lang/pub/issues/2190#issuecomment-1482613347 This same husky use case is what I was trying to solve that led me here.
@hyiso Husky led me come here
I also came here because of husky.
I don't quote agree that adding above mentioned hooks would make it more dangerous than it is now.
- The hooks are only executed in the current package that's been fetched for development with source code.
- Once a developer fetches a repo, they run
dart pub getto then build the code and run it. - In all cases they should already trust the repository, as they're going to run:
- some code from package build
- the reset of the package
Basically you're folks saying that it's fine to deploy malicious code in the build script, but not in the proposed hooks :)
Correct me please if I'm wrong.
Basically you're folks saying that it's fine to deploy malicious code in the build script, but not in the proposed hooks :)
Yeah - you are right that to use the package you need to trust it. But I'd still claim there's a difference between using, and retrieving with pub get. It is very easy to get a package you don't intend while playing with constraints.
IMO package code should not be run before you had a chance to verify pubspec.lock that you have the packages you expect.
Furthermore I don't think pub get is the right time to build stuff - at that point you don't know the target platform, defines etc. We need a dedicated build step.
And luckily there's work underway to create dart build and a hook/ folder with scripts for preparing native code, and other build stuff. "Native Assets" https://github.com/dart-lang/sdk/issues/50565
I think I'll Close this in favor of https://github.com/dart-lang/sdk/issues/50565, which I believe is the right point for a package to insert custom operations.