-
-
Notifications
You must be signed in to change notification settings - Fork 76
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
provide hook for resolving binary dependencies and bundling them in zip file #6
Comments
I have been giving some thought on how to solve this and would like your opinion. How would you feel of having a By using inversion of control, the final user would have much more flexibility and we could also set sane defaults. |
Any update on this? |
I would still like to try to tackle this issue, but I'd like a green light from a contributor to make sure the effort wouldn't be for nothing. @softprops you seem to be the main contributor, could you give your opinion here? |
Sounds good. What's the approach you'd be leaning towards? I don't want to be a blocker here |
What I'm imagining is something like this:
The consumers of Using the 3-digit notation before the name, I propose the initial
The reason behind these numbers is the ability to add a significant amount of scripts before or after each step of the build process. Example:
The scripts would be run in the following order:
If one scripts fails (i.e., returns non-zero) then the whole process would fail. Possible problems and solutions:
I can't think of other problems or possible things that could break. Do you have any insights here or have I covered all the cases? What is your opinion on the approach? |
My preference would be to remove as much ceremony as possible so there's less to maintain for users that don't need this feature. I bit of the recent debug options have has started to feel that way. As much as possible only design for what you need and nothing more. As few considerations. I separately maintain a serverless framework plugin for rust which leverages this builder for building rust lambdas consistent with the lambda runtime env. There are some discussions around adding support for building lambdas in a host env outside of docker. That becomes more complicated as this docker image does more than just a cargo build. I see the default case for cargo is not needing anything at all. Cargo provides built-in support for a build script that will automatically get ran. I like the idea of lifecycle hooks but I'm not sure about the need for having multiple copies of them. There operations I see are Install Currently there's a hook to yum install extra deps if you need them as docker run args Line 19 in cff2b3a
Build Caro build is pretty basic as mentioned above it comes out of the box with build script support Line 25 in cff2b3a
Package This one is very has a very specific contract. The lambda runtime expects a zip file with an executable called "bootstrap" inside it. That's essentially all we're doing now Line 46 in cff2b3a
"scripts" is pretty common name for a utility dir. I'd like to avoid surprises if you happened to have a scripts dir with a script sharing the same name has one of the hook scripts we'd be introducing and have it not be intended for use with this yool. I'd suggest something a bit more specific to the tool. In this case perhaps If you'd like to start sketching something out given the above feedback is be open to it. I'm a fan of iterating with small changes then learning how well they work in practice before making big changes. If there's a way to implement one of these hooks and see if it solves a problem that would be cool too. |
I like your ideas. I'll your concerns point by point.
I don't understand what you mean. If there are discussions about adding support for building lambdas outside docker, what does it have to do with this project?
The rationale was to provide users that need high flexibility the possibility to customize the process as they see fit. But I agree that it may be over-engineering at this point.
It's possible to add files to a zip file using the
I agree that Thanks for the thorough feedback! I plan to start working on this shortly |
see softprops/serverless-rust#23 for context
This should be pretty straight forward. sketch thoughts, capture whats missing from the output of
ldconfig -c -new -p
from the list of dependencies provided byldd {bin-name}
. The most straightforward to expose such a hook is likely the presence of an env variableZIP_DEPS
or something similar.The text was updated successfully, but these errors were encountered: