Skip to content
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

move scripting libraries on disk to make reuse easier #109

Open
dbendele opened this issue Jun 14, 2021 · 1 comment
Open

move scripting libraries on disk to make reuse easier #109

dbendele opened this issue Jun 14, 2021 · 1 comment
Labels
enhancement New feature or request

Comments

@dbendele
Copy link
Contributor

Is your feature request related to a problem? Please describe.
Scripting APIs for Import, ARINC 429, Shared, and Ballard should be organized on disk during export and installation to promote reuse without requiring installation of unnecessary packages.

Describe the solution you'd like
I would imagine the ARINC 429 library, Import library, and Shared being located at VeriStand Custom Device Scripting APIs/ARINC 429 and the Ballard 429 library going to VeriStand Custom Device Scripting APIs/Ballard/ARINC 429. Again, it doesn't have to be done for this PR, unless it makes it easier on you. The main idea is to keep the generic ARINC 429 libraries separated from the Ballard library so we can reuse them for other custom devices.

Describe alternatives you've considered
Status quo dumps all scripting libraries under Ballard/ARINC 429

Additional context
Installation directory structure reflects built structure. It is pretty easy to change the example project dependencies if we later decide to change the structure. I would like to build the palette soon, and that is very coupled to the installation file structure but can be changed easily enough using the palette API. Do you have a vision for what you want the structure to look like on disk?

This also makes it much easier to create the two separate nipkg files outlined in the design spec. If the files are in different top-level locations, it makes building the packages much easier.

@Karl-G1
Copy link
Contributor

Karl-G1 commented Jun 29, 2021

No need to do this for the first release.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants