chore(roadmap-v1): welcome on sprout 🌱

[42atomys]

Migrating to Sprout 🌱

Introduction

Welcome to the roadmap for our ambitious project: Evolve Sprig to Sprout. This project is inspired by the core ideas of Sprig, a Go template function library known for its robustness and ease of use. Our mission with Sprout is to take the foundation that Sprig has laid down and evolve it further, addressing some of the challenges and limitations we've identified. Our ultimate goal is to create a more streamlined, efficient, and user-friendly template function framework that can cater to a broader range of use cases without compromising on performance and flexibility.

Important

The oraganisation @go-sprout are ready to receive the project 🎉 I will finish the PR https://github.com/42atomys/sprout/pull/14 to complete all the documentation and migration to transfer the repository on go-sprout/sprout 🎉 🚀

Key Objectives

Below are the specific objectives we aim to achieve with the Sprout project:

1. Minimize Dependencies

Reduce the number of external dependencies to mitigate frequent update cycles, making Sprout more stable and lightweight.

2. Enhanced Documentation

Provide comprehensive, easy-to-understand documentation that covers all functionalities, use cases, and examples to improve the developer experience.

3. Conventional Function Naming

Establish clear, consistent naming conventions for functions to enhance code readability and maintainability. Unlike Sprig, where function naming varies between camelCase, and snake_case, and similar functions lack consistent prefixing, Sprout will introduce a standardized approach to function naming. This will make the library more intuitive and reduce the learning curve for new users.

4. Reduce memory fingerprint

Aim to minimize memory allocations as much as possible to alleviate the burden on the garbage collector in large-scale applications. By optimizing the way memory is used within the framework, we ensure that Sprout is not only efficient in its functionality but also in its resource consumption. This approach contributes to overall better performance and scalability of applications using Sprout.

5. Native Error Handling

Introduce built-in error handling mechanisms for all functions to ensure that errors are managed gracefully and efficiently.

• 🌱 error handling: create a complete and robust error handling #6

6. Advanced Error Handling Strategy

Implement a custom error handling framework utilizing channels for improved error reporting and handling on the Go side, reducing the risk of template crashes.

• 🌱 error handling: create a complete and robust error handling #6

7. Expanded Function Set

Add a broader array of functions without imposing limitations, enabling users to accomplish more tasks directly within the framework.

8. Customizable Function Loading

Allow users to customize which functions to load into their runtime environment, preventing unnecessary resource consumption and enhancing performance.

• 🌱 functions loading: create a complete solution to load specific function #10
• 🌱 custom functions: allowing developers to create their own functions #11

9. Function Aliasing

Enable the creation of aliases for functions outside of the library, providing flexibility and convenience in how functions are accessed and utilized.

• 🌱 functions aliasing: allow to create alias for existing functions #3

The Path Forward

Achieving these objectives will require a collaborative effort. We're calling on developers, documentation specialists, and anyone passionate about creating a more efficient and user-friendly template function framework to contribute. Whether it's through coding, providing feedback, or contributing to documentation, every bit of help pushes us closer to our goal.

How to Contribute

Interested in contributing? Here's how you can help:

Code Contributions: If you're a developer looking to add new features, improve existing ones, or help with bug fixes, check out our issues section and pick something that interests you.
Documentation: Good documentation is key to any project's success. If you have a knack for writing and wish to improve our docs, we'd love to hear from you.
Feedback and Ideas: Have ideas on how we can improve Sprout? We're all ears. Open an issue with your suggestions, no matter how big or small.

Conclusion

Migrating to Sprout represents not just the evolution of a framework but a collective journey towards building a more resilient, efficient, and inclusive tool for developers. With your support, we can create something truly special that stands the test of time and serves the needs of the community. Let's grow together! 🌱

[42atomys]

You can now retrieve all informations directly on the documentation site : https://docs.atom.codes/sprout/roadmap-to-sprout-v1.0

[andig]

I don't find the related comment but I'd agree that it would be great to have an org if this should be a long-term evolution of sprig.

[42atomys]

Thanks @andig for suggesting we move the project to an organization. I’m seriously considering it! However, I’m a bit concerned about the potential disruptions it could cause at this early stage of the project, I use features from GitHub Team, and migrate to an organization force to me to repay it. I still open to your inputs 🌱

To manage imports, I’m thinking about setting up a vanity URL (following the doc site, so something like atom.codes/sprout). This will allow us to migrate without disruption in the future. Does that sound like a good interim solution? I’d love to get your feedback with emojis 👍 or 👎!

Your insights are incredibly valuable to me, so please don’t hesitate to share your thoughts!

See you 🌱

[andig]

Does that sound like a good interim solution?

I honestly don't know. It was horrible (but also done very late) for mergo.

[42atomys]

It was horrible (but also done very late) for mergo.

Yes agreed do it too late can be a nightmare and broke a lot of things.

I love vanity for the flexibility that give to maintain transparently from the end devs, but I hate it for the SPOF that can create

[ripienaar]

There has been several renames - mergo, expr, logrus comes to mind immediately - and to be blunt it was all a complete disaster for users, there are no good outcomes from renaming a project.

I'd say this being in a org is a MVP level requirement to avoid the issues we are trying to get away from.

And no, not a vanity url either - a github org.

[andig]

I've claimed https://github.com/go-sprout (sprout is not available). Let me know if you'd like to hand that one over or if there are better ideas.

[42atomys]

I try to takes go-sprout too ahah
After few combinations of sprout and go and don't found one, I take "gardenkit" and in future maybe grap other repo to maintain it in a beautiful garden 🪴

I currently facing to the "pay" issue due to the charge that add for me to double pay the Pro features (for me account and for the org)

[42atomys]

PS: I have finish some part of the default settings of the organization (and launch the sponsor feature because that takes few days)

I also contact GitHub to be able to transfert it without lose the fork reference (for the moment I think is better to keep the fork reference)

[andig]

@42atomys I own go-sprout. I'll invite you and happy to step out :) Invited you as owner.

[42atomys]

Thanks for reserve it @andig 🙏, do you want to still a member of the org ? This is a problem for you if I change your role to member ?

I hesitate now between have a single org like "go-sprout" and only have sprout in it or have something like more flexible like "gardenkit" and allow us to have more repositories in future (Be the eternal garden of abandoned repositories) 🫠🐐

Your inputs are welcome, this is a little point but important to define where we want to go in long term 💪🔥

[andig]

It's all yours ;) gardenkit sounds nice but is not obvious. I have no further opinion on naming.

[42atomys]

Not a simple choose because that will be definitive!

I put you member, for the moment and see contribution to decide, actually you are an active member in issue discussions 🌱 so thanks you

[42atomys]

UPDATE: I currently waiting for approval of Github for Sponsorship on https://github.com/go-sprout organization to migrate the repository and continue the roadmap 🚀

[42atomys]

UPDATE: The oraganisation are ready to receive the project 🎉 https://github.com/go-sprout
Thanks again @andig for the reservation !

I will finish the PR #14 to complete all the documentation and migration (estimated this week) to migrate the repository and release the v0.3 as the first stable version on go-sprout/sprout 🎉 🚀

[andig]

I think it would be important to find a small team to maintain this. You're enthusiasm is great- but sooner or later life will happen...

[andreynering]

Thanks for the effort on this project! I'm interested in it as a possible substitute for sprig on Task.

One of the changes I made on slim-sprig, on top of removing external dependencies, was removing all functions related to crypto (crypto.go), because:

1. I noticed they considerably increased the build time and binary size of the projects that imported sprig.
2. Most of the functions are not useful at all for a template library. Perhaps I could have kept a couple of them (base64, sha256), but encrypting stuff, generating bcrypt passwords, certificates, etc. are things that 99.99% of the user won't need on a template engine. And the minority that really need them can add them manually.

In short, I advice you to clean non-useful functions from this fork as well.

[ripienaar]

Would agree on removing the crypt stuff, they are not useful

[42atomys]

Hello everyone, I’ll address each point in a single message 💜

@andig

(...) find a small team to maintain this. You're enthusiasm is great- but sooner or later life will happen...

I completely agree; it's premature to form a team before reaching the first stable version. As the sole maintainer, I'm committed to providing guidance and feedback to everyone until we can establish a team.

@andreynering :

I'm interested in it as a possible substitute for sprig on Task.

Thank you for your interest! I’ll monitor your issue closely at go-task/task#1638 and will respond to any questions there. Please feel free to remind me if necessary!

@andreynering & @ripienaar :

removing the crypt stuff

Regarding issue #14, the remaining cryptographic elements need to be migrated, and I believe including them in a template was a mistake. I am planning to remove them, and see you have the same vision than me.. I think is a good time to think about "future vision"

Request for Feedback 📢

Initially, I envisioned a seamless transition from Sprig to Sprout without any changes. However, I've noticed several aspects that don't align with my vision (such as using panic in template functions instead of handling errors gracefully). I’d like to gather your opinions on the following:

Would you prefer:

• 1️⃣ To have a v1 of Sprout that is seamlessly compatible with Sprig as a fork maintained project, followed by a v2 that incorporates our improvements and features?
• 2️⃣ To start directly with a stable v1 that reflects our vision, accompanied by a guide or cli-tool to facilitate migration from Sprig to Sprout on a function-by-function basis?

[andig]

I'd be happy with 2. No point in doing 1 if that's not the long-term intention.

[caarlos0]

I'd vote for 2 as well

[ripienaar]

Vote for 2

[andreynering]

I'd vote for 2, but it's important to keep in mind that we should keep compatibility where possible, and only change what makes sense. The easier it is to migrate, the better.

[42atomys]

@andreynering, I agree with your points, this is my main objective to have an easy way to migrate for everyone.

Here's my plan concerning the "crypto" functionality, which I'll refer to humorously as "the C word" . I intend to ensure it remains compatible by not enabling it by default. This approach allows users who rely on it in Sprig to continue using it in Sprout as well without impact all devs performance. I don't have a clear vision of who I will do that but I think about it

To facilitate this transition and maintain backward compatibility, I've implemented an alias feature, which you can find more about in our documentation on function aliases. You can also view an example of a backward compatibility alias here.

Additionally, I'm planning to introduce a Loader Feature in v1. This will allow developers to selectively load only the functions they need, rather than all functions by default.

If there are any other considerations we should discuss 💜🌱

[42atomys]

UPDATE: I'm currently drafting a roadmap for out v1 with migration steps from Sprig and will be opening multiple discussions in the coming days and weeks. This will allow us to exchange ideas in a RFC format or through solution proposals.

I look forward to your contributions and insights! 💜🌱

[ripienaar]

There are a number of crypt functions using out of date, deprecated and dangerous alogrithms, its not responsible to keep these due to backward compat concerns.

[42atomys]

UPDATE: The project has found its permanent home at https://github.com/go-sprout/sprout 🌱 🚀

[andig]

Love the logo 😘

[42atomys]

Thanks @andig! I made it myself. Pixel art is a passion of mine, and the Gopher on it is really fun!

[42atomys]

UPDATE: First RFC of the project about Function Loader available here https://github.com/orgs/go-sprout/discussions/31