Re: Re: [PATCH 0/4] Add import builtin

[Koichi Murase]

2024年5月6日(月) 14:28 Matheus Afonso Martins Moreira <matheus@matheusmoreira.com>:
> > 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.

I thought that part "it potentially reduces thousands and thousands of
lines of code" in [1] was a part of describing "what Matheus thought
before submitting the patch", but now we shared that the situation in
module managers is not like that. Isn't it?

[1] https://lists.gnu.org/archive/html/bug-bash/2024-05/msg00053.html

Anyway, it's never true that thousands of lines are reduced by the
suggested feature.

> However many lines that is, this feature would allow me
> to reduce them all to zero by not actually needing a
> module manager.

It's trivial that your code reduces to zero because you designed your
builtin to satisfy your needs. That doesn't show anything about its
generality.

> At the very least, it will save users from having to
> implement an import function themselves.
> They could still do it but they won't have to.

That argument would apply to any other useful shell functions, but I
don't think we should make everything builtin.

> >  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.

That's the source builtin.

> With the ergonomics you expect it to have. With good defaults, no setup.

It's just your expectation of the ergonomics but not ours. The
suggestion would be more useful for sure, but it doesn't mean it's the
best. You haven't made any survey on existing implementations.

> That's an incredibly huge change.

If it were really "incredibly huge", I would try to block this change
to carefully think about the impact in the future, other
possibilities, and a possible better solution (e.g. with
shell-function implementations or with a possibly different interface
of a builtin). However, don't worry, I don't think the actual impact
is that large...

> Especially considering how little code
> was required to make it happen.

The submitted patch seems unneededly large. It also touches something
else including incomplete addition of the long option of builtins, and
an incomplete support for the XDG base directories, which should
actually be discussed separately.

> People see bash as a language that scales down instead of up.
> The shellcheck tool helps a lot with shell script development but
> managing complexity is still quite difficult.

What's wrong with it? Even on this list, I think people's attitude
about the future of Bash varies, but I don't think the community
thinks Bash should replace or compete with Python or other general
purpose scripting languages. The shell language is not a language
intended to scale up in general, though it is free to attempt that in
personal projects. I think Bash might acquire a necessary feature in
the future, but I don't think we should hastily add every unnecessary
feature just because that seems useful. Honestly, if we think about
the necessity, I don't think the suggested feature is indispensable.

> This could really change that.
>
> > AFAICT the only thing this proposal addresses is your personal
> > hangup about using PATH to find sourced files
>
> It's not a personal hangup.

It does seem your personal hangup not giving a filename extension to
the script files, which ended up with mixed script files to be sourced
and executable files.

> Alternatively, you reinvent part of the functionality of source
> by resolving the path yourself and giving it an absolute path.
> None of these solutions seem right to me.

If you think that is the problem, your suggestion doesn't actually
solve the problem of module managers. Module managers will have to
implement it by themselves to satisfy their needs (which is obviously
different from your ergonomics) even if your feature is added to Bash.

> > Much like the periodic requests for XDG-organized startup files
>
> I think I deserve at least a little more credit than that.
> [...] _the bash maintainer_
> replied to my email saying he thought it was a
> reasonable feature.

Is this your rebuttal to Lawrence's "The sourced files that can be
written with your feature available are exactly the same as the ones
that can be written right now. Much like the periodic requests for
XDG-organized startup files.". If you avoid discussion by showing the
relation with the authority, it seems a proof of lacking a
straightforward counter argument. In addition, as far as I understand,
Chet mentioned the additional variable for the locations to search,
but not a new builtin or a flag.

> I interpreted that as a strong
> signal that this would be a welcome contribution.

I don't think a welcome contribution means the merge without any
reviews and discussions. If the proposed change is not convincing to
others, it's normal that a discussion arises. The current situation of
the long discussion is still within the normal range in the bug-bash
list.

> 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.

If the maintainer would have requested you to work on it and you've
accomplished precisely what the maintainer had requested, it is
understandable that you'd think it'd be unfair that your work was not
considered. However, as far as I understand, no one has requested you
to work on this. You've voluntarily appeared on the help-bash and
bug-bash lists and submitted patches. Then, of course, there are both
possibilities of acceptance and rejection after the discussion. It's
unfair to request 100% merge just by a vague reply from the maintainer
at the point where the detailed implementation wasn't even revealed.

> My only request here is that you seriously consider the work
> of a fellow software developer for merging into master. That's all.

Do we need to merge every patch unconditionally after discussions? I
don't think so.

Even if it would not be merged, no one thinks your work was useless
because the discussion itself is valuable.

> > even convinced it merits a new "source" option.
>
> Why not?
>
> The addition of this new builtin turned out to be
> a significant change, much bigger than I anticipated.
> I quickly agreed that it would be better as an option
> to the existing source builtin which is a much more
> conservative solution. I've even sent the new patchset.
>
> It is no longer a significant change.
> It's not even a significant amount of code.

The code change seems too large considering the amount of the feature
change, but I haven't yet checked the code. I'll later check them.

> It adds a useful feature, and does so in a way
> that does not cause any incompatibility.

Usefulness is not a unique and sufficient measure. All the patches
submitted to OSS are supposedly useful of course, but not all the
patches would be merged in general. We need to think about whether it
is consistent with existing features, whether it is the best solution,
whether it doesn't add unnecessary maintenance cost, etc.

> Yet the feature has been described as "irritating"!
> I really don't understand the cause for this
> and it's making me feel really unwelcome.

You should be prepared to receive negative comments in the review
process. The reviews are not always 100% positive. This is normal.