All changes - handle go nested packages

[matiit]

If the changes to, for example, sql assets are located within nested directory, we want to get the information of which go package that data is nested in.

[rentziass]

Hey 👋 isn't this assumption a bit unsafe?

// Non go files belong to the closest package

It might be the case or it might not, but if users take for granted that a change in those file will mark relevant packages as changed that might be dangerous. I've always wanted to make this change but for embedded files, just never got around to it, good to see someone is looking after this.

Also this kinda defeats the purpose of making builds more efficient, a change in a readme next to go code would mark the package as changed right?

[matiit]

@rentziass
Hey 👋 Thanks for having a look at that, much appreciated!

You're totally correct,

Also this kinda defeats the purpose of making builds more efficient, a change in a readme next to go code would mark the package as changed right?
This is the case.

Here comes the reasoning though:

• It doesn't have to be used - one can still pass the allFiles: false and everything works as it was before
• I want to use it because of, specifically, editing migration files made us adding ugly scripting to our CI code to cater for these exceptions - so there's an improvement
• Next step, I want to implement a config/parameter (not sure yet), some way to pass an array of choices that I want monitored - so for example - I would like to only be bothered by changes in .go and .sql files, or I want to be only bothered by .go files and !.md (not md files) etc. - or even some included/excluded paths.

Currently trying to figure out what would be the best interface for doing that, as you know we call patrol indirectly - by using cx mage target that uses patrol as dependency. My initial thought is starting with how I want this to be cleanly represented in CI actions - then pass it forward all the way to patrol. And deciding on the features scope we will really need - for now we're gonna see how it behaves in real life - how often is this really an issue (do we change just .md files that often etc.).

Hope that makes sense.

[rentziass]

It does make sense yes, but with these last few PRs the goal of patrol is shifting from solving a "Go problem" to becoming more of a "UW build tool", which isn't wrong per se, it's just a different direction. I personally would have tackled this from a different angle trying to use embed, that way we could have stayed in the "solving a Go problem" realm and at the same time mark those dependencies more clearly (which isn't a perk only for CI builds).
What happens if not only the closest package to a changed non-Go file also depends on that file?

As per the all-files flag, personally I think git + scripting should be the way there but again, I had a different perspective on what patrol is/should be :)

Something I think you should consider, patrol in my opinion is a bit of a missed opportunity: it solves a real problem for Go monorepos using standard Go tools. I think with a bit of advertisement this project could actually become quite visible (and in turn do good for UW, who would do good for the community). Turning this into a tool tailored for UW needs does the opposite imho but also, if no one cared enough about the above I don't see why you shouldn't turn this into a tool that's convenient for your use cases :)

[matiit]

Thanks for giving more context.
I have to say, I haven't taken patrol's being go specific tool into mind, I just seen it as a tool that was already being used and I wanted to change it to bend to my needs. I can totally see where you have an issue with though.

I agree that the https://pkg.go.dev/embed would be a good way to solve my problem - I will be more than happy to revise it this way.

To re-iterate, I myself don't have an intention of Turning this into a tool tailored for UW, quite the opposite, it was more of a - get things done thing.

If you have some goals for patrol, would you mind sharing them? I would love to contribute in my free time.

As for the all files functionality - I will drop this once I find a time and change the way how we use it, is it fair enough?

Thanks again for engaging, and looking forward to speaking to you more.

[rentziass]

That was just an opinion I swear, not a directive! The way this started was to build a Unix-like tool with zero opinions that goes "here's a list of packages that changed, do what you want with it", and we really didn't want to keep vendoring dependencies (a requirement at the time for digitalocean/gta) and we also didn't want to commit hard to something like Bazel. There's no wrong way of going about this to be honest, it's all about picking a direction for the project and my opinion counts much less than yours!

I'd be happy to help, I've been wanting to come back and do the embed part for months, but you know how it goes 😄 as far as Go is concerned though I believe if you were to add that this would be feature-complete (Go-wise)?