search

Homebrew / brew

🍺 The missing package manager for macOS (or Linux)
https://brew.sh
BSD 2-Clause "Simplified" License
41.54k stars 9.77k forks source link

Automatically create formula 'resource' entries from `go.mod`/`go.sum` (like `update-python-resources` / `homebrew-go-resources`) #16261

Closed 0xdevalias closed 12 months ago

0xdevalias commented 12 months ago

Verification

Provide a detailed description of the proposed feature

update-golang-resources is a proposed tool for Homebrew, designed to automate the creation and maintenance of resource blocks in Go-based formulae. This tool will extract dependencies from a Go project's go.mod and go.sum files and automatically generate Homebrew resource blocks, ensuring accurate and up-to-date dependency management.

For more information on specifying dependencies in formulae, see the Homebrew Formula Cookbook.

What is the motivation for the feature?

The primary motivation behind update-golang-resources is to simplify and streamline the process of contributing and maintaining Go-based formulae in Homebrew.

Currently, the manual addition and updating of Go dependencies in Homebrew formulae is a tedious and error-prone process.

This tool aims to bring the ease and reliability of Python formulae management, as seen in the Python for Formula Authors guide and the update-python-resources tool, to the Go ecosystem in Homebrew.

How will the feature be relevant to at least 90% of Homebrew users?

update-golang-resources will be relevant to a significant portion of Homebrew users because Go is a widely-used language for many popular tools and applications. By making it easier to contribute and update Go-based formulae, this tool will enhance the overall quality and reliability of the Homebrew repository, benefiting not just Go developers but all users who rely on Go-based tools.

What alternatives to the feature have been considered?

An alternative approach was the use of an external tool, as mentioned in the Homebrew documentation. The homebrew-go-resources tool was an early attempt to address this need but is now outdated and unmaintained.

update-golang-resources would serve as a modern, integrated solution within Homebrew, offering a more seamless and up-to-date method for managing Go dependencies in Homebrew formulae.

Bo98 commented 12 months ago

Difference with Python is dependencies are rarely versioned so we need to do it for reproducible builds.

With Go however, that information is already there in go.sum so we typically don't need any resources.

Currently, the manual addition and updating of Go dependencies in Homebrew formulae is a tedious and error-prone process.

Is there existing formulae that is doing this?

0xdevalias commented 12 months ago

With Go however, that information is already there in go.sum so we typically don't need any resources.

Oh true. Yeah, that makes sense; though I had a shadow of a memory (that may never have existed) of it still being required for some reason.

I think the current docs/formula handbook/etc confuse that issue a bit too; so maybe the real request here is just to improve those docs so people who aren't super familiar with how this all works don't get as confused as I was this morning.

Is there existing formulae that is doing this?

I don't think I'd looked through many examples when I opened this this morning; was still trying to figure out how to do it in the simplest way possible; but after looking at a few examples today while making my 2 recent PR's, none of the gong examples I looked at seemed to be using resources.

MikeMcQuaid commented 12 months ago

Difference with Python is dependencies are rarely versioned so we need to do it for reproducible builds.

Passing on this for this reason. We've had private conversations recently even calling into question whether we should continue to use brew update-python-resources (conclusion: we should) or take this pattern into other languages (conclusion: we should not). Sorry!

0xdevalias commented 12 months ago

@MikeMcQuaid It feels like you skipped past the currently relevant point in this issue in a rush to close it:

I think the current docs/formula handbook/etc confuse that issue a bit too; so maybe the real request here is just to improve those docs so people who aren't super familiar with how this all works don't get as confused

MikeMcQuaid commented 12 months ago

@0xdevalias We leave "I was confused by X" issues open when we see evidence that multiple people are confused by them.

Again, as I said in the other issue, please adjust your tone. I was not "in a rush to close it"; I'm triaging issues on an active project used by a lot of people. You will get better results from your communication on projects like this if you drop the insinuation (in both here and your other issue) that you know better about how to run some aspect of the projects than the folks who have been doing it for over a decade.

0xdevalias commented 12 months ago

please adjust your tone

@MikeMcQuaid There was no 'tone' in my above message. There was a statement of events as I perceived them based on the actions that played out. Please don't project your perception onto my words as though it's an objective reality, and then tarnish me by that perception.

You closed the issue, citing a reason that didn't mention the documentation point at all. That gives the impression (rightly or wrongly) that you missed it. Thus I pointed it out, assuming that perhaps it was an innocent mistake as you no doubt have a lot to deal with in "triaging issues on an active project used by a lot of people". Then you scold me for acting in good faith, and (on the other issue) also wonder why that leaves a bad taste in ones mouth..?

You will get better results from your communication on projects like this if you drop the insinuation (in both here and your other issue) that you know better about how to run some aspect of the projects than the folks who have been doing it for over a decade.

@MikeMcQuaid I'm not attempting to insinuate anything. I am providing an outside perspective and frustration for a process (or in this case, lack of documentation) that seems to cause more friction than value.

Keeping this issue focussed on the main point; I'd invite you to put aside your "over a decade" of experience on this project" for a moment (and the biases that level of intimacy brings), and embrace a beginners mindset: a new user looking to contribute a formula, doing their best to follow the processes and documentation and jump through all of the hoops to do so correctly.

Now from that place, I'd invite you to go back to the post above (Ref), and read what was said there with regards to the documentation again. Within the context of a formula for a Golang binary, does the documentation as written suggest to you (as a new contributor), that you need to create resource blocks for the dependencies? Or does it suggest that "With Go however, that information is already there in go.sum so we typically don't need any resources"?

If you can't or won't do that, that's fair enough; I'm not here to tell you how to run your(?) project. Just trying to help (and feeling kicked down for doing so).

MikeMcQuaid commented 12 months ago

There was no 'tone' in my above message. Please don't project your perception onto my words as though it's an objective reality

I am letting you in on what my perception is. This is important because: 1) I'm a human and I have feelings and my feelings are important to me 2) I'm the technical lead of this project and if you want to convince me of things: what I perceive is important of that

If your communication is not landing as intended with me: you will have an easier time adjusting your communication (and, yes, tone) than telling me that my perception is wrong.

Your comment in the other issue:

This has once more reminded me why I've tended to avoid spending my time contributing to homebrew; so thanks for that :)

does not set up maintainers (including myself) to treat this issue completely independently of your tone (yes, that again) and communication in that other issue.

Within the context of a formula for a Golang binary, does the documentation as written suggest to you (as a new contributor), that you need to create resource blocks for the dependencies?

I think it's ambiguous and can be read either way. If you would like to clear up that ambiguity: please open a pull request, I will happily review it.

Just trying to help (and feeling kicked down for doing so).

I am also trying to help you to understand:

0xdevalias commented 12 months ago

@MikeMcQuaid translated through ChatGPT to avoid 'tone':

Considering the attention you've placed on the 'tone' of my written messages, I'm opting for a different method. I'll have ChatGPT 'translate' my responses to ensure they are objective and free of emotional nuance. This approach, while not standard, highlights how our conversation has shifted from the key issues of the project to the emotional nuances of text-based communication. It's crucial to remember that written words can be easily misinterpreted and overemphasizing tone can sidetrack us from the substantive content and productive dialogue. My hope is that this method refocuses our discussion on the actual issues, rather than on personal interpretations of 'tone'.

If your communication is not landing as intended with me: you will have an easier time adjusting your communication (and, yes, tone) than telling me that my perception is wrong.

@MikeMcQuaid translated through ChatGPT to avoid 'tone':

Respectfully, I understand your perspective as the project lead and recognize the authority you hold in these matters. However, I feel it's important to express that the approach of suggesting someone adjust their communication instead of acknowledging the potential validity of their perception can come across as dismissive. This can create an environment where feedback is not fully welcomed or valued, potentially discouraging contributions from the community. I agree that effective communication is key, but it's equally important to foster an open dialogue where different viewpoints are considered constructively. While I acknowledge your leadership and the final decision-making power that comes with it, I hope we can find a more collaborative way forward that encourages diverse contributions and perspectives.

I think it's ambiguous and can be read either way. If you would like to clear up that ambiguity: please open a pull request, I will happily review it.

@MikeMcQuaid translated through ChatGPT to avoid 'tone':

Fair enough, and I appreciate the invitation to contribute directly through a pull request. I'll need to reflect on this and see how I feel tomorrow. Honestly, at the moment, my enthusiasm for investing further time into improving the project is quite low, particularly with the current dynamics of our interaction. However, I do recognize the value in constructive collaboration, so I'll reconsider my stance after some thought.

I am also trying to help you to understand:

  • how your communication is being received and why that is detrimental to your goals (leaving aside the feelings of those involved with this project who have been trying to help you)
  • how to best get things done on this issue tracker and project

@MikeMcQuaid translated through ChatGPT to avoid 'tone':

I appreciate your perspective on effective communication within this project. However, it's essential to remember that communication is a two-way street. While I'm open to adjusting my approach to better align with project norms, it's equally important for there to be a reciprocal understanding and adaptation. My feelings and perceptions, as a contributor, also hold significance. They influence my willingness and motivation to engage with the project. For a truly collaborative environment, it's vital that all parties involved are open to both giving and receiving feedback, and making adjustments where necessary. This reciprocal understanding is key to fostering a productive and respectful working relationship.

MikeMcQuaid commented 12 months ago

It's crucial to remember that written words can be easily misinterpreted and overemphasizing tone can sidetrack us from the substantive content and productive dialogue. My hope is that this method refocuses our discussion on the actual issues, rather than on personal interpretations of 'tone'.

No. This is exactly the opposite approach from what is required. The correct approach is to consider the feelings of the other human involved, iterate on your communication style and, most easily of all: just say "sorry" sometimes. I'm not going to spend my time reading ChatGPT output, I'm locking all issues where this has been done and you will be blocked from the Homebrew organisation if you continue to do this in future and/or not have more productive conversations with maintainers.