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

[Matheus Afonso Martins Moreira]

> it doesn't need to be implemented as a builtin

It doesn't need to be implemented this way.. But it could be.
It's true that a whole new builtin was overkill but the discussion
still pointed to a better solution in the form of source --import.
This is a more conservative approach but it's still a builtin
which means advantages such as widespread availability,
PATH preservation, general ergonomics.

>  Yes, that is a problem in directly using the source builtin, but I
>  think the original intention for the design of `.' and `source' is
>  that the library shouldn't have the same name as exiting commands.
>  Again, this is related to the improper setup of the library. Then,
>  there is always the possibility of a name conflict between different
>  libraries that share their names even if it doesn't conflict with
>  executable files. Yeah, but sourcing an executable file can be more
>  problematic than sourcing a different library.

It's an issue of namespaces. I think it's wrong for libraries
to share the same namespace as executables and commands.
By placing them in separate file system locations and searching
by means of different PATH variables, separate namespaces are
established and kept isolated from each other, making such clashes
all but impossible and also giving greater freedom to library authors.

>  However, I shall note that some shell programs are intended to be used
>  as both a library and a separate program.
>  For the above reason, I think you still need to search for both types of 
> files.

I understand now. Looks like filtering by executable attribute
was not such a good idea after all.

>  But what I wanted to say is that the `import' builtin should be an
>  opt-in feature, i.e., it should be disabled by default to avoid
>  conflicts with existing `import'.

That makes sense and I agree. I think the better solution
is to add this functionality as an option to source instead.
This way, existing code can continue to define their own
import functions and no clashes should occur.

>  No, those files need to be distributed by the Bash package of
>  distributions, and the path needs to be properly set up.

Then I don't think that would be the ideal solution.

>  [1] 
> https://github.com/niieani/bash-oo-framework?tab=readme-ov-file#using-import
>  [2] 
> https://github.com/akinomyoga/ble.sh/wiki/Manual-%C2%A78-Miscellaneous#user-content-fn-ble-import
>  [3] 
> https://github.com/basherpm/basher?tab=readme-ov-file#sourcing-files-from-a-package-into-current-shell
>  [4] https://github.com/modernish/modernish?tab=readme-ov-file#simple-form
>  [5] 
> https://github.com/bash-bastion/basalt/blob/main/docs/reference/api.md#basaltload
>  [6] https://github.com/ko1nksm/modulesh/blob/master/README.md#import
>  [7] 
> https://github.com/scop/bash-completion/blob/c48854850f702604aeb600ae496fb6b2eb840f8e/bash_completion#L3127
>  [8] 
> https://github.com/ohmybash/oh-my-bash/blob/9cfb35c946953cb8cc1511cce47986cdd630852a/oh-my-bash.sh#L52

It's embarrassing but the truth is I was not even aware of these projects.
Truly, it was not my intention to just override everyone else's work.
I apologize if I came across that way because of my ignorance.

My intention was simply to add a feature I wanted to bash.
I experienced difficulty with maintaining a growing collection
of personal scripts, had this idea, coded it up and sent patches.
I had the foresight to email help-bash first and ask what others
thought of the idea, my impression was that the idea was well
received despite some perfectly valid concerns.

> Is your design of the `import' builtin based on any real frameworks?

It certainly is not. Nor would I claim to have any real frameworks of my own.
All I have is a growing collection of scripts in my dotfiles repository.
I was hoping to make it more organized by adding this feature to bash.

I suppose I could say I based this design on the system
I implemented in the programming language I created.
I'm far from being any kind of authority on the subject
but I did study the library systems of numerous other
languages in order to do it. So it might not be informed
by large scale usage but it's not based on nothing either.

>  Also, if you are going to propose "the standard mechanism", you will
>  have to survey those implementations to investigate what would be
>  demanded by the real use cases.

I'd be happy to discuss the matter with everyone.
I'm sure their expertise will be invaluable.
The reason I did not do it was ignorance.
I literally did not know they existed.

>  I also think the variation is actually needed because the assumed
>  search paths are different for different libraries. We cannot simply
>  merge all those implementations into a single command because each
>  library wants to limit BASH_IMPORT_PATH to the locations they provide.

Why is this required?

>  Then, it's identical to `PATH=<path> source'. I also think the
>  variation is not a problem. The separation of the domain is useful.

Please elaborate on this point. How is it useful?

> If desired, the developer can choose one module framework
> and write their module for that module system.

I think it's counter productive when developers have to choose
which module system to develop for. There should be only one.
Having many leads to fragmentation of the ecosystem.
You cannot use module X and Y because they use different
frameworks or they were written for a different framework
than the one you chose for yourself. This reduces the ability
to reuse code.

> Or the developer can develop own module system.

I'm generally of the opinion that the user and developer should
have the power to do whatever they want. They should be able
to rebuild everything from scratch if they want to.

At the same time, I believe that there's exactly one exception
to the above rule: the module system of a programming language.
I think there should be exactly one library system,
and that it should be literally built into the language.
Anything else leads to the fragmentation of the ecosystem.

>  I'm not sure if it's useful to try to kill all existing
>  module frameworks and start from the beginning.

It's not my intention to kill any other projects.
I don't think this proposal has the power to kill anything either...
It might even prove useful for other frameworks.
Should a native bash system be accepted,
they could be integrated with it.

>  If that works, you can define and export the shell function `import'
>  within those "sensible defaults" by the user or by the distribution.

It could be a variable that's overridable at build time via configure.
Linux distribution packagers can adjust it to their needs.

Thanks for the feedback,
  Matheus