packer v1.33

[kal247]

Many changes according to discussion in :

#507

[briandfoy]

I have another idea for this because I think I'm blocking this issue simply by not knowing enough about packer and having too many other things to do. If I can get out of your way so I'm not the blocker, maybe we (you) can get this done.

First, I'd like to give you permission to make releases. This is imperfect, but you good generate the single file and release it on GitHub. That way, at least it's out there and downloadable. One of the issues has always been distribution since this sort of thing doesn't fit nicely in CPAN. We could make a link to the latest in the GitHub pages.

Second, I would not mind if you started a second repo with this one as a submodule. In that repo you could do whatever you want and not be blocked with me figuring out how to integrate your stuff. That might involve a cronjob (GitHub Actions can do that) that makes a release when there is a new release-* tag in this repo.

Third, you could work in this repo through pull requests. One idea is to figure out a GitHub Action that generates the single file whenever it sees a new release-* tag. You could start with the .github/workflows/release.yml, or maybe even expand on that.

Fourth, I get saddle up and figure it out. I need to add something on my side to create the file when I release the new version. You don't see those details in this repo because it's my usual Module::Release process. Maybe I need a Module::Release::PerlPowerTools plugin to do this work. But, realistically, you've seen how something I think should be simple has escaped me. Totally my fault.

Finally, if you have any other ideas how I can get out of your way, suggest that. I think I'm the point of failure here and I don't see that changing soon. I like what you've done and want to do.

[kal247]

Hello, considering our respective situations, I think it makes sense to approach this step by step and postpone automation a bit.

So yes, I can build releases on my laptop and "upload" them to your repository.

For the second point : I should make a new repo - let's say kal247/Packer - having a submodule briandfoy/PerlPowerTools, so I can update my version of the tools when you make changes. Then try and automate building and releasing the executable. Right?

You're not blocking me, instead showing me new possibilities (I had to google "submodule") so thanks.

[briandfoy]

I'd call your repo something like kal247/perlpowertools-exe or something descriptive and specific. Let's start with that and go from there.

[kal247]

https://github.com/kal247/perlpowertools-exe

[briandfoy]

Good news. I'm going to close this issue and we can do everything in the new repo. You still have all your commits in your fork, and I'm not going to delete any branches here for awhile.

[briandfoy]

Although I changed that status to 'rejected', that's just some administrative stuff I have to track PRs that reached their conclusion without being merged, which is different than open PRs that are not complete or closed PRs without a status (which could be anything). It's not a judgment on the idea.