Conversation
There was a problem hiding this comment.
I think all the modules inside the std widget that import other modules should use the widget keyword in the path. This way we avoid looping through the ARIA_LIB_DIR dirs each time, follow our own style guide rules and, as an extra, we don't rely on the name of the folder to make it work.
There are also other suggestions that come to my mind but that I don't think we should take care of them now:
- ARIA_LIB_DIR_EXTRA is no longer necessary as I don't see any case it is useful.
- We should have two types of environments when running
Aria. One of them would be the system installation ofAria, where general use tools can be installed. The other one should be something similar to the python virtual environments, with a script like python'sactivatethat defines ARIA_LIB_DIR pointing to a new folder inside thevirtual environment. This is useful to make reproducible environments for scripting or developing with Aria and, at the same time, we avoid breaking or making dirty our system installation.
Don't disagree. I can make that change in this pull request.
I would have to think about it a bit more, but given your next suggestion...
In which case, I guess you would have a copy of the standard widget, and you would just point ARIA_LIB_DIR to the root of the venv? |
|
About virtual environments. One use case I can think of is having a .aria script to plot some data or read a file format and convert it to .txt, but I don’t want the required widgets to be installed on my system or on other contributors’ systems. I also don’t want to deal with environments that already have one of the widgets installed but in an incompatible version. With a virtual environment and a setup script, all contributors would have the same installation regardless of their system, they would just need one compatible version of Aria installed. And yeah, the std widget would also be installed in that virtual environment directory. The structure would look something like this: borja@GV62-7RD:~/Desktop/project$ tree -a
.
├── Cargo.toml
├── script.aria
├── set-up.sh
├── src
└── .venv
├── activate
├── bin
│ ├── aria
│ └── widget_manager
└── lib
├── aria
└── other_widgetThe activate script would put you into a subshell so that ARIA_LIB_DIR doesn’t get overridden when leaving it. As I said, it’s just an idea, I don’t think this is the right time to implement it. |
No description provided.