-
-
Notifications
You must be signed in to change notification settings - Fork 48
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Search for modules after packages has been exhausted #307
Comments
This is a thoughtful feature request but it is at odds with the current, intentional design. There are two classes of problems with this design, which I’ll explain in the following. But first, here’s how globally installed (as opposed to project-local) modules are intended to be used:
R packages are not scoped, and this has several problems. Foremost, it leads to name clashes between different sources. In the case of R, CRAN packages always take precedence. This isn’t just a theoretical problem: for years, ‘box’ used to be only hosted on GitHub, and it had to be renamed three times (‘modules’ → ‘mod’ → ‘pod’ → ‘box’) because successive packages on CRAN “stole” its name. There are other, arguably more serious problems (e.g. it facilitates security vulnerabilities via typosquatting of module names). On balance, I feel that the pros of requiring scoped module names outweigh the cons. But I am open to counter-arguments. (For a broader perspective, the issue of scoped vs. flat module names is a extremely widely debated issue across module systems in many different languages — e.g. here — and while the debate is far from settled most people seem to agree that having scope would generally be better than not having them, and that retrofitting them into a flat system is problematic.) The other issue with your proposal is that it unfortunately introduces an error-prone API. Once again the culprit is name clashes: consider the case where, in the future, you install an R package ‘bar’ on your computer. Installing ‘bar’ automatically installs its dependencies, and one of the dependencies is called … ‘foo’. And suddenly your code breaks, without any changes to it. Simply because (indirectly) installing the package ‘foo’ has changed what code gets loaded by This kind of silent errors is something that ‘box’ aims to avoid at any cost. In other words, if there will ever be the possibility of using flat module names, they won’t be usable simply via |
Would you be open to expanding the box syntax to indicate a global module vs a package name? the formula operator Maybe something like:
I understand the intention behind wanting some projects namespaced, I just enjoy being able to use the I'll leave the final decision in your hands, but if you like the idea, I can revise the pull request to try and implement this feature. |
I’m not sure what you mean by that: you can use That being said, I am not dogmatically opposed to “flat” module names. Maybe I need to revisit my objection to them. As for syntax, I’m unsure what would be best. I have no definitive answer but here are a few other ideas that feel like they might make more sense (in no particular order). Apologies, unfiltered stream of consciousness ahead:
… of course this is non-exhaustive; one of the dangers of using NSE is that you can go wild with the syntax. One more consideration: I’ve used … it’s fair to say that I’ve painted myself a bit into a corner, syntactically, by making |
My logic behind using
I understand how the
I hope this clears things up. If this feature request does not make it into the package I am also okay with that. I can always restructure my code. |
It does, thanks. I still haven't decided how to best tackle this feature request but I will add some way of using unscoped modules. |
Apologies for the radio silence, it was a combination of life happening and me having issues with my computer which lead to my dev environment crashing constantly. Anyway, please have a look at the work in progress PR #316 (branch feature/unscoped-mod-names) which implements a preliminary version of this feature. For now (and I need to stress that this is temporary!) the syntax for loading an unscoped module box::use(mod(global_module)) Here, Before settling on a final syntax and merging this feature I would appreciate test-driving this feature. |
I understand life - I too have been very busy. I will give this feature a go in my day to day. Cheers! |
Please describe your feature request
Lets assume you have set the systems
R_BOX_PATH
environment variable to something like/opt/box
. It would be convenient to take advantage of the__init__.r
usage pattern with modules within/opt/box
.For example, suppose the following directory structure in
/opt/box
foo/__init__.r
foo/mod1.r
foo/mod2.r
Then, the expected result may look something like this:
Instead, we currently get an error dictating that there is no package named
foo
. Thus back to my point, to there being some convenience ifbox
would then start searching the paths.I am aware that if
R_BOX_PATH
had/opt
set, then the following usage may workBut in my case, there may be other things within
/opt
that I do not want thebox
package to walk over.The text was updated successfully, but these errors were encountered: