Thank you for your feedback. You raise an important point regarding the build-time complexity.

One potential solution, I have in mind when I read your comment to address the issue of unwanted compile-time dependencies, especially for pre-built functions in sprout, could be the use of sub-module imports. This approach allows for selective inclusion of dependencies at build time, ensuring that only the desired functionalities are compiled. For example:

import (
 "github.com/go-sprout/sprout"
 _ "github.com/go-sprout/sprout/modules/math"
 _ "github.com/go-sprout/sprout/modules/crypto"
)

By using this method, you can include only the specific modules needed for your project, reducing unnecessary compilation of unused functions.

Your concerns about security with dynamically or template-initiated loading are valid and I share it. Indeed, This kind of features must be disabled by default to safeguard against potential security vulnerabilities. 👮

Additionally, the dynamic loader feature of sprout supports loading functions from external libraries while leveraging sprout's standardized features for template management. This can greatly enhance flexibility and maintain standardization across different parts of your application.

Yeah an import based approach would be good.

I am curious if anyone else monitoring this thread ever had a need for the complexity outlined here, what real world scenarios this is for and maybe some repos that exist on github exhibits the need. I am struggling to see the use case.

@ripienaar is right. Choosing which functions we're going to include is nice and we could have that, too. But by far the most important here is to have crypto/etc on a separate package so that won't even be imported/compiled for those that don't want to, to save compilation time and binary size.

Talking about crypto... I think there's room to have two packages here. There are some sprig function like sha256 that could perhaps be useful to more folks, but bcrypt and certificate functions (and etc) should be pretty rare. So the options are:

1. Keep only checksum functions, but on a separate package. Ditch other useless crypto functions out.
2. If we want to keep compatibility with sprig, we could that those crypto functions but on a separated package, only for those who want it. Separate checksumming and crypto.

Thanks for your feedback, @andreynering. We are aligned on the necessity of separation. For backward compatibility, my vision is to provide a v0.x version compatible with seamless migration, accompanied by a simple migration guide to transition to v1.0 once it is released.

Regarding the crypto/checksum functions, we can indeed separate them easily. We can create more packages to allow for a more granular selection of functions.

Some libraries or applications may require specific functions. Therefore, having a package import strategy as the default is essential. Additionally, we can leverage the power of go generate to let libraries or applications compile their package with only the necessary functions, achieving an "import perfect" setup. (This can fit perfect with the other RFC safe/must )

The most notable case involves the import of third-party packages in a package that renders multiple templates. An example will make it clearer:

// mypackage/render.go
package mypackage
import (
 "github.com/go-sprout/sprout"
 "github.com/go-sprout/sprout/hello"
 "github.com/go-sprout/sprout/crypto"
 "github.com/go-sprout/sprout/pkga"
 "github.com/go-sprout/sprout/pkgb"
)
func renderTemplateA(handler *sprout.FunctionHandler) {
 // Register handlers in the registry for use in templates
 handler.RegisterHandlers(crypto.NewCryptoHandler(handler))
 // Execute the template
 tpl := template.Must(
 template.New("base").Funcs(handler.Registry()).ParseGlob("*.tmpl"),
 )
}
func renderTemplateB(handler *sprout.FunctionHandler) {
 // Register handlers in the registry for use in templates
 handler.RegisterHandlers(pkga.NewAHandler(handler), pkgb.NewBHandler(handler))
 // Execute the template
 tpl := template.Must(
 template.New("base").Funcs(handler.Registry()).ParseGlob("*.tmpl"),
 )
}
func renderAll() {
 globalHandler := sprout.NewFunctionHandler(
 sprout.WithLogger(slogLogger),
 sprout.WithAlias("hello", "hi"),
 )
 globalHandler.RegisterHandlers(hello.NewHelloHandler(globalHandler))
 renderTemplateA(globalHandler)
 renderTemplateB(globalHandler)
}

Automatically registering a package upon import can be convenient in certain scenarios but problematic in others. Here are the key points:

1. Declarative Approach:

• A declarative approach provides clarity and control over the code's behavior.
• Explicitly registering handlers makes it clear which components are being used and where.

2. Configuration Sharing:

• Sharing a general configuration (e.g., FunctionHandler with a logger, error handler, etc.) with third-party packages becomes more complex if automatic registration is enforced.
• By manually registering packages, the user has full control over how and when configurations are shared.

3. User Choice:

• Allowing users to register packages declaratively empowers them to make informed decisions about their codebase.
• This flexibility ensures that the code remains modular and maintainable, especially in larger projects with multiple dependencies.

In summary, while automatic registration of packages upon import might seem convenient, it undermines the benefits of a declarative approach and complicates configuration management.
It is better to give users the choice to register packages explicitly, maintaining clarity and control over their code.

Again, I would love to see actual real world cases where these use cases and requirements came up.

To me, this is a show stopper, this project seem to HEAVILY optimise for the most complex way to solve any problem without any evidence that this is needed.

As a fork of sprig, this makes it a no go to me. I am probably done with this tbh.

It's important to keep in mind the ease of use and simplicity of sprig and the fact that the functions are just a map and how easy it is to manipulate that in just pure go, without all these Javaescue design patterns.

It has to be easy to use and get out of your way, the direction here is very much to get in your way as much as possible.

Now I appreciate that complexity is needed and often adds value - but thus far there is no evidence that anyone in sprig or here ever needed this and the ROI of this complexity is going to be net negative imo.

Thank you for the thoughtful discussion on the registration mechanism for handlers. After carefully considering the pros and cons of both automatic and explicit registration, I believe that explicit registration aligns better with the principles and long-term goals of this project.

As a fork

As a fork we needs to be easy to use, and seamless from sprig. That the challenge : have a seamless transitions with a good future following vision, and go specification, for new projects and large projects.

The discussion between vision are done in the issue #1, I can understand for small project that an inconvenient, for larger projects, this is another thing.

Reasons for Choosing Explicit Registration

1. Clarity and Transparency: Explicit registration makes it clear which handlers are being registered and when. This improves code readability and makes it easier for new contributors to understand the system. As highlighted in the Effective Go guide, clarity and simplicity are fundamental principles of Go. Explicitly stating what is being registered enhances transparency and adheres to Go’s idiomatic practices .
2. Control and Maintainability: Explicit registration allows for fine-grained control over what gets registered, reducing the risk of unintentional registrations or conflicts. This is particularly important as the project grows and becomes more complex. The Go Language Specification emphasizes precise and controlled coding practices, which are best achieved through explicit declarations .
3. Debugging and Modularity: When issues arise, explicit registration makes it easier to trace the source of the problem. Additionally, it supports a more modular design, which is beneficial for maintaining and scaling the project. Go’s Effective Go also discusses the importance of modularity and clear code organization for maintainability and ease of debugging .

Addressing Concerns

I understand that some contributors find the automatic registration more convenient. Here are a few steps we can take to mitigate the perceived drawbacks of explicit registration:

1. Improved Documentation: We will enhance our documentation to include detailed guidelines and examples on how to register handlers explicitly. This should help reduce the learning curve and make the process more straightforward.
2. Helper Functions: We can provide utility functions to streamline the registration process. These functions will encapsulate common registration patterns, reducing boilerplate while maintaining the benefits of explicit control.
3. Feedback Loop: We will establish a channel for continuous feedback where contributors can share their experiences and suggest improvements. This will help us refine our approach and address any pain points promptly.

Conclusion

While automatic registration offers simplicity, the long-term benefits of explicit registration in terms of clarity, control, and maintainability make it the preferred approach for our project. I appreciate your understanding and cooperation as we implement this change. Let’s continue to work together to build a robust and maintainable codebase.

For further reading on Go’s best practices, I recommend the Effective Go document and the Go Language Specification

Thank you again for your contributions and ongoing support.

PS: I’m not good with the idea of making auto-register and declarative ways works together to be everyone happy, but I still open to discuss with you and others people to have a bigger feedbacks loop

PS2: I think the best choose are to make two projects: sprout with new changes and go-sprout/sprig the fork without any changes