On Mon, May 6, 2024, at 1:27 AM, Matheus Afonso Martins Moreira wrote: >> I fail to see how this could possibly save "thousands and thousands >> of lines of code". > > How many lines of code were needed to implement the module managers? > Probably a lot of lines. I guessed it was in the "thousands of lines" > ballpark. > > However many lines that is, this feature would allow me > to reduce them all to zero by not actually needing a > module manager. And the benefit would be multiplied > by all the users of bash which is probably the most > ubiquitous shell there is. That's a lot of benefit.
Surely these module managers do more than simply implement an alternate search path? >> You keep talking about this proposal as if it would spark a huge >> sea change in script maintenance, but I just don't see it, at all. > > A native way to source libraries. Built into bash, available to all users. > With the ergonomics you expect it to have. With good defaults, no setup. > > That's an incredibly huge change. > Especially considering how little code > was required to make it happen. > > [...] > >> The sourced files that can be written with your feature available >> are exactly the same as the ones that can be written right now. > > It's possible but it's not as easy or ergonomic as it could be. At this point it doesn't even feel like we're talking about the same thing. > I think the best solution is to just avoid all that by adding another > variable. > This approach resolves all the above concerns. It also reuses bash's > pathname resolution code and has the added benefit of being native > to bash and available to all users, eliminating the requirement that > they implement this themselves or install an external dependency > just to load libraries. For the record I think it would be fine to introduce a new variable BASH_SOURCE_PATH that changes the behavior of "source" in non-POSIX mode. I don't think "source" requires a new option to use this. >> Much like the periodic requests for XDG-organized startup files > > I think I deserve at least a little more credit than that. > This was not some simple drive-by feature request. I didn't say or mean to imply that it was; I was just comparing it to another suggested feature about which I have a similar opinion. The presence or absence of patches has nothing to do with it. (By the by, at least two implementations of XDG startup files have been submitted in the past.) > But I don't think it's fair at all to just dismiss it as a "request". > The code has been written and as far as I can tell it works > and makes bash better than it used to be. I even made sure > to separate the commits into logical changes so that the > the maintainer would be able to cherry pick the general > refactoring improvements even if the overall feature was > rejected in the end. It was my intention to do at least some > good even if this turned out to be a stupid idea in the end. And I appreciate the effort you've put in so far. > My only request here is that you seriously consider the work > of a fellow software developer for merging into master. That's all. Everyone has been seriously considering it. That doesn't mean they have to agree about it. >> BASH_SOURCE_PATH might be convenient >> but is not groundbreaking and probably >> doesn't merit significant changes to the shell. > > I can't speak for others but I'd say this feature > is going to be quite ground breaking for me. > It's going to significantly and permanently > change the way I use bash. I'm going to write > lots of little libraries. I'll release them as free > software too. My dotfiles repository is AGPLv3. I simply don't see why you can't do all of this right now, as many other people do. >> even convinced it merits a new "source" option. > > Why not? Current commands don't need an option to use their associated path-like variables (BASH_LOADABLES_PATH for "enable", CDPATH for "cd"). -- vq
