Skip to content

Conversation

@egranata
Copy link
Collaborator

@egranata egranata commented Nov 3, 2025

No description provided.

@egranata egranata requested a review from ZocoLini November 3, 2025 03:16
Copy link
Collaborator

@ZocoLini ZocoLini left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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 of Aria, where general use tools can be installed. The other one should be something similar to the python virtual environments, with a script like python's activate that defines ARIA_LIB_DIR pointing to a new folder inside the virtual 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.

@egranata
Copy link
Collaborator Author

egranata commented Nov 3, 2025

I think all the modules inside the std widget that import other modules should use the widget keyword in the path

Don't disagree. I can make that change in this pull request.

ARIA_LIB_DIR_EXTRA is no longer necessary

I would have to think about it a bit more, but given your next suggestion...

similar to the python virtual environments

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?

@ZocoLini
Copy link
Collaborator

ZocoLini commented Nov 3, 2025

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_widget

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants