Both of these, if adopted, would mean that packages such as Pkger, Packr, Statik, etc... will no longer be necessary.
So what does that mean for the future of Pkger? Great question! For that I want to seek community input and help.
Multiple Choice
There are many different ways that Pkger can react to these proposals. I would like to walk through a few different approaches that have come to me, but I would encourage others to leave alternate ideas, proposals, etc...
When I refer to "we" below, I mean not just me, but the community. Projects like Pkger are difficult to maintain. They hit many, many edges cases due to the nature of the problem. To fix those issues, or to implement any of the following proposals, will require help from the community.
So, with that said let's look at the two most obvious choices.
1: Ignore the Proposals
Definitely the simplest approach. Those proposals are draft proposals after all and we aren't obligated to take them into account at all. They, if accepted, would take several cycles to get into the language and command. Therefore a need will exist for third party static embedding tools.
2: Implement the Proposals
Definitely the hardest approach. The Pkger tool and library would be re-architected to implement the proposed changes from the Go team.
By its original design, Pkger, tries to mimic the standard library by creating wrappers around the os and io packages, amongst others. The Go team proposals present similar interfaces and concepts.
A change like this would break compatibility with the current versions of Pkger. Considerations around module naming, i.e. markbates/pkger/v2, gobuffalo/pkger, gobuffalo/embed, etc... would need to be decided.
In this scenario the Go team would get early feedback of these proposals, and could act as prototype keeping with any changes in the proposals.
Implementing the proposals directly would also mean that Pkger could be swapped out directly with the official implementations, so they get accepted.
Like I said, there are a lot of other approaches that could be taken, and I would love to those as well as feedback on the two I outlined above.
Recently the Go team presented the following to proposals for the Go language and tool chains.
Both of these, if adopted, would mean that packages such as Pkger, Packr, Statik, etc... will no longer be necessary.
So what does that mean for the future of Pkger? Great question! For that I want to seek community input and help.
Multiple Choice
There are many different ways that Pkger can react to these proposals. I would like to walk through a few different approaches that have come to me, but I would encourage others to leave alternate ideas, proposals, etc...
When I refer to "we" below, I mean not just me, but the community. Projects like Pkger are difficult to maintain. They hit many, many edges cases due to the nature of the problem. To fix those issues, or to implement any of the following proposals, will require help from the community.
So, with that said let's look at the two most obvious choices.
1: Ignore the Proposals
Definitely the simplest approach. Those proposals are draft proposals after all and we aren't obligated to take them into account at all. They, if accepted, would take several cycles to get into the language and command. Therefore a need will exist for third party static embedding tools.
2: Implement the Proposals
Definitely the hardest approach. The Pkger tool and library would be re-architected to implement the proposed changes from the Go team.
By its original design, Pkger, tries to mimic the standard library by creating wrappers around the
osandiopackages, amongst others. The Go team proposals present similar interfaces and concepts.A change like this would break compatibility with the current versions of Pkger. Considerations around module naming, i.e.
markbates/pkger/v2,gobuffalo/pkger,gobuffalo/embed, etc... would need to be decided.In this scenario the Go team would get early feedback of these proposals, and could act as prototype keeping with any changes in the proposals.
Implementing the proposals directly would also mean that Pkger could be swapped out directly with the official implementations, so they get accepted.
Like I said, there are a lot of other approaches that could be taken, and I would love to those as well as feedback on the two I outlined above.