randomdsdevel / brew Goto Github PK
View Code? Open in Web Editor NEWThis project forked from homebrew/brew
🍺 The missing package manager for macOS
Home Page: https://brew.sh
License: BSD 2-Clause "Simplified" License
This project forked from homebrew/brew
🍺 The missing package manager for macOS
Home Page: https://brew.sh
License: BSD 2-Clause "Simplified" License
Note: This issue was previously named/titled:
[Feature Request] Add Support for Step-Into Debugging Homebrew With pry-byebug
Please replace this section with:
A detailed description of your proposed feature:
When troubleshooting an issue with Homebrew or one of its various and sundry available formulas, the tool's users may occasionally wish to understand how it's behaving during execution given any particular invocation. Some useful techniques to do this are those of step-into debugging. An oft-recommended tool for doing such debugging in Ruby code is pry-byebug
. Users should be able to tell Homebrew to execute itself within the context of pry-byebug
.
The motivation for the feature:
Originally, I yearned for this functionality while debugging a particular formula (vim
, when installed --with-client-server
when its python
dependency is installed --with-tcl-tk
; I'd reference the associated issue here, but that would spam it with an unneeded in-thread GitHub notification.) It occurred to me while hacking my way around doing this without the feature proposed here that the functionality in question could prove useful not only in my current situation, but also in an untold future number of debugging scenarios involving Homebrew itself or one of the formulas directing its actions; people troubleshooting problems of any of this sort in the past would likely also have loved to have access to such tooling then, too.
How the feature would be relevant to at least 90% of Homebrew users (if it's not: do not open a feature request:)
Any effort to ease understanding, and thus maintainability, of a software project should find a warm welcome among its maintainers and contributors. The feature proposed/requested here would go a non-trivial length of the way towards enabling Homebrew internals and formula developers to better understand the package manager's behavior when it fails to match their expectations.
(N. b.: This text could likely be improved substantially, but I'm leaving it as is for now.)
What alternatives to the feature you have considered:
Alternatively, the pry-byebug
-based debugging functionality proposed here could instead not be implemented. Homebrew internals and formula developers would then continue to temporarily insert ad-hoc code for tracing execution into brew
's implementation as they do now. This approach, however, brings along with it at least the following few problematic pain points:
Anybody wishing to debug a 'require
' statement to see why it's not finding something will need to step over, not into, its implementation's uses of 'RUBYGEMS_ACTIVATION_MONITOR
;' trying to introspect them quickly leads to deadlock and a crashed Pry session.
Homebrew's internal implementation easily spawns multiple processes, each with their own separate entry point within the project's source code. Pry needs a separate in-code invocation for each of these entry points; otherwise, entering each new one of these beyond the one through which the tool was first brought to bear either allows execution past them to continue unhindered by its introspection capabilities or causes the user's Pry session to hang while attempting to do that. Examples of such entry points include, relative to Homebrew's repository root:
FormulaInstaller#build
(currently starting on line 718 of 'Library/Homebrew/formula_installer.rb
' as of this writing.) This uses:
Utils.safe_fork
,' regardless.Sandbox.exec
' if using the build sandbox, as is the default. (Disable-able using brew
's '--no-sandbox
' argument or 'HOMEBREW_NO_SANDBOX
' environment variable as a workaround.) (Note that this is especially problematic, as the sandbox used for this operation has no provisions in place for Pry to run without running up against its restrictions.)I'll document more examples of such trouble as I remember or run into them.
Other alternatives may well exist, but have not yet been considered for addition to this issue documentation.
The proposed functionality could, in future, be extended to allow users to specify a particular section in Homebrew's code from whence to start tracing brew
's execution, thereby avoiding any overhead incurred by stepping through the preceding code manually. This or any other such further improvement would, however, likely involve modifying `breathe program's source to include additional complexity beyond what would be necessary to implement what I've initially proposed here and is thus not put forth for consideration at the current time.
(Note that I didn't submit this issue upstream because I've already been asked to create a pull request for this instead.)
(Notes:
Please replace this section with:
A detailed description of your proposed feature:
When troubleshooting an issue with Homebrew or one of its various and sundry available formulas, the tool's users may occasionally wish to understand how it's behaving during execution given any particular invocation. Some useful techniques to do this are those of step-into debugging. Users should be able to tell Homebrew to execute itself within the context of a suitable Ruby debugging tool.
An oft-recommended tool for doing such debugging in Ruby code was pry-byebug
. 'byebug
,' the tool that pry-byebug
extended Pry with capabilities from, has, however, long since become unmaintained. A (fairly straightforward) replacement likely exists, but I haven't yet done enough research to find out yet.
The motivation for the feature:
Originally, I yearned for this functionality while debugging a particular formula (vim
, when installed --with-client-server
when its python
dependency is installed --with-tcl-tk
; I'd reference the associated issue here, but that would spam it with an unneeded in-thread GitHub notification.) It occurred to me while hacking my way around doing this without the feature proposed here that the functionality in question could prove useful not only in my current situation, but also in an untold future number of debugging scenarios involving Homebrew itself or one of the formulas directing its actions; people troubleshooting problems of any of this sort in the past would likely also have loved to have access to such tooling then, too.
How the feature would be relevant to at least 90% of Homebrew users (if it's not: do not open a feature request:)
Any effort to ease understanding, and thus maintainability, of a software project should find a warm welcome among its maintainers and contributors. The feature proposed/requested here would go a non-trivial length of the way towards enabling Homebrew internals and formula developers to better understand the package manager's behavior when it fails to match their expectations.
(N. b.: This text could likely be improved substantially, but I'm leaving it as is for now.)
What alternatives to the feature you have considered:
Alternatively, the debugging functionality proposed here could instead not be implemented. Homebrew internals and formula developers would then continue to temporarily insert ad-hoc code for tracing execution into brew
's implementation as they do now. This approach, however, brings along with it at least the following few problematic pain points:
Anybody wishing to debug a 'require
' statement to see why it's not finding something will need to step over, not into, its implementation's uses of 'RUBYGEMS_ACTIVATION_MONITOR
;' trying to introspect them quickly leads to deadlock and a crashed Pry session.
Homebrew's internal implementation easily spawns multiple processes, each with their own separate entry point within the project's source code. Pry needs a separate in-code invocation for each of these entry points; otherwise, entering each new one of these beyond the one through which the tool was first brought to bear either allows execution past them to continue unhindered by its introspection capabilities or causes the user's Pry session to hang while attempting to do that. Examples of such entry points include, relative to Homebrew's repository root:
FormulaInstaller#build
(currently starting on line 718 of 'Library/Homebrew/formula_installer.rb
' as of this writing.) This uses:
'Utils.safe_fork
,' regardless.
'Sandbox.exec
' if using the build sandbox, as is the default. (Disable-able using brew
's '--no-sandbox
' argument or 'HOMEBREW_NO_SANDBOX
' environment variable as a workaround.) (Note that this is especially problematic, as the sandbox used for this operation has no provisions in place for Pry to run without running up against its restrictions.)
CAUTION!
Upstream has begun considering deprecating and obsoleting/removing both --no-sandbox
' argument and its 'HOMEBREW_NO_SANDBOX
' environment variable. (Note: I need to go back and find where this has been discussed.) This will make it impossible, or at least extremely difficult, to debug any potential issues with the sandbox, but upstream considers its build and process sandboxing functionality stable enough that it won't need any further debugging regardless of how true that turns out to be in the future.
I'll document more examples of such trouble as I remember or run into them.
Other alternatives may well exist but have not yet been considered for addition to this issue documentation.
The proposed functionality could, in future, be extended to allow users to specify a particular section in Homebrew's code from whence to start tracing brew
's execution, thereby avoiding any overhead incurred by stepping through the preceding code manually. This or any other such further improvement would, however, likely involve modifying `breathe program's source to include additional complexity beyond what would be necessary to implement what I've initially proposed here and is thus not put forth for consideration at the current time.
(Note that I didn't submit this issue upstream because I've already been asked to create a pull request for this instead.)
Per this comment by Mike McQuaid in upstream issue Homebrew#16725:
I think it'd be worth trying to be more consistent here and use this as an opportunity to drop some older macOS versions support entirely.
upstream may consider dropping support for OS X v10.11.x 'El Capitan' in the near future. This is pretty much entirely on me for getting myself stuck in development purgatory regarding my local development hardware environment over multiple years, but:
Also:
@gromgit currently maintains a fork of Homebrew Core for macOS Mojave v10.14.x, but I have no idea if he'd be willing to:
brew
' itself for El Capitan support if/as needed. (Aside: …If I could find someone to offload some of this work off onto who'd be willing to take it on, I'd definitely be open to taking them up on that offer. No potential interest has yet been raised, however, either locally or online. Also, package manager and build system code, especially for system package managers and systems programming languages, can be…disheartening/overwhelming, particularly for less-experienced developers like me. Avoiding it this time around could deprive me of a development learning experience, though. Additionally, I've already had some non-trivial thoughts on how it'd be nice to have some of the code structured if I were indeed to be the one to put the refactoring work in on it, even though this was only starting from brew
's entry point and not having gotten very far past that at all, and the thought/prospect of code ownership remains…non-trivially tempting despite the requisite investment of time that I currently still lack.)
Once I – finally! – have the old machine back up and running again:
Dump or manually document what Homebrew packages I currently have installed for explicit end-user use.
Dumping them using an automated method could prove difficult or impossible, however, as:
I installed, upgraded, or re-installed some formulas' formula dependencies manually, because I (originally) did so either:
This left some packages marked as installed on request when they should've been installed as dependencies. 'brew leaves --installed-on-request
' and 'brew bundle dump
' therefore won't report a proper formula list back to me. (There isn't a 'brew bundle dump --leaves
' for help with this scenario yet, either, at least not as far as I know/am aware.) Homebrew has:
emerge
's '--oneshot
,' which I've only discovered/encountered much more recently after studying to play around with/use Gentoo inside Windows Subsystem for Linux 2.Switch to another macOS package manager like:
at least temporarily, referring back to the list of packages compiled previously.
Homebrew's formula package definition syntax is by far the nicest I've seen and easiest to work with as a contributor, though, so I'll miss it dearly.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.