Comments (5)
I agree it is not convenient but it is powerful. This, to me, suggests that something built on top of Yakut would be in order. Perhaps a VSCode plugin that uses Yakut and injects workspace defaults as Yakut defaults, does git pull of the public, regulated types, etc? I think opportunities to simplify the command-line would be accepted (I'm not the maintainer here though) but I don't think it's a good idea to provide any pre-compiled data types or otherwise tightly bind the tool with the types. While gui_tool worked well with little to no configuration the auto-magic defaults quickly became an impediment as our systems matured. I don't want to have that kind of inflexibility nor hidden behaviours in Yakut.
from yakut.
Just to be clear, I'm not advocating for removing configuration, but for providing convenient defaults instead.
Regarding bundled datatypes, what if YAKUT_PATH
defaulted to ~/.yakut
(or %APPDATA%/yakut
) and it would be automatically populated with public types on first launch or with a yakut install
? Opting out is just changing YAKUT_PATH
, which you already have to do.
from yakut.
Initial confusion is that the first command given in the README is
yakut --path=/the/path compile path/to/my_namespace --output=destination/directory
. However, I could not understand why it needs 3 paths for compilation.
It is a bad example that needs to be improved. The point of that snippet is not to illustrate how to invoke the yakut compile
command, but to show the relationship between options and environment variables. Should it be replaced with another command here? Maybe something like yakut --format=json subscribe --count=1
? A pull request improving this (and perhaps something else in the readme) would be appreciated.
Then README explains to setup environment variables so that default compilation output goes to user data directory. Wouldn't it be better to have this as default instead of current working directory? AFAIK, this is the most common use case.
I am generally okay with that change but I am not entirely sure if it is actually better than the current behavior because when it comes to generating anything, by default the user would expect the output to show up in the current working directory. Maybe we could provide a dedicated command that sets up the default system configuration when run, like yakut setup
(which would edit .bashrc
or whatever automatically)? But then we would be missing out on the opportunity to demonstrate to the user how to use environment variables to override the defaults. That said, see below on implicit DSDL generation support in PyCyphal.
Another option is to provide an automatic installation script that does all these things automatically per system, like:
bash -c "$(wget -O - https://raw.githubusercontent.com/OpenCyphal/yakut/main/setup.bash)"
# Also 'setup.pwsh' for Windows, etc.
Would it be possible to ship public regulated data types together with yakut?
No, this is not going to happen. In v0 it was a terrible decision that led to much confusion, causing many developers and vendors to fork the public regulated repository just to add some obscure application-specific types to the standard uavcan
namespace. The current README actually has a paragraph with the rationale behind the lack of precompiled namespaces, also Scott basically already answered this in his post above.
Or maybe add a command that would download and compile them for you?
This is not as bad but then would it be much different from simply copy-pasting the public regulated data type URI to your shell? Compare:
# A helper command specifically for the public regulated data types:
yakut compile-public-regulated-dsdl
# What we have right now, where the URI is copy-pasted from the README:
yakut compile https://github.com/OpenCyphal/public_regulated_data_types/archive/refs/heads/master.zip
Actually, we already have a snippet in the README that merely needs to be copy-pasted to compile the standard namespace, so I would say that it is pretty much a non-issue? Maybe I am missing something though.
Another convienient option would be to load custom DSDLs from user directory and compile them automatically, as was the case with uavcan_gui tool.
Absolutely. This is tracked in PyCyphal with a slightly different bent: OpenCyphal/pycyphal#153. I want to get rid of the notion of DSDL pre-compilation completely (but it won't rid you of the need to download DSDL sources). Would you be inclined to help with that? I expect this to improve the UX of Yakut and PyCyphal scripting significantly.
There's also the outstanding problem of migrating the Python DSDL generator to Nunavut but it appears to be unaffected by this change (@coderkalyan was working on this for a while but right now the effort seems to be stagnating).
from yakut.
Then README explains to setup environment variables so that default compilation output goes to user data directory. Wouldn't it be better to have this as default instead of current working directory? AFAIK, this is the most common use case.
I am generally okay with that change but I am not entirely sure if it is actually better than the current behavior because when it comes to generating anything, by default the user would expect the output to show up in the current working directory. Maybe we could provide a dedicated command that sets up the default system configuration when run, like
yakut setup
(which would edit.bashrc
or whatever automatically)? But then we would be missing out on the opportunity to demonstrate to the user how to use environment variables to override the defaults. That said, see below on implicit DSDL generation support in PyCyphal.
If yakut could implicitly compile DSDL's then this is no longer an issue and compile
could work as is.
So if I understand the concerns correctly, my proposal would be:
- Make
YAKUT_PATH
default to~/.yakut
or%APPDATA%/yakut
(when no env variable exists and--path
is not given) - Implement OpenCyphal/pycyphal#153
- Simplify DSDL installation. Here I can see a couple of options:
- Tell user to manually download DSDL to
~/.yakut
or%APPDATA%/yakut
. If compilation is no longer required this is already a great improvement. - Add
yakut dsdl install https://github.com/OpenCyphal/public_regulated_data_types/archive/refs/heads/master.zip
and maybe a shorthandyakut dsdl install-regulated
, which could be optionally invoked duringyakut setup
(if it is implemented).
- Tell user to manually download DSDL to
Driver autodetection or configuration during yakut setup
would also be nice, but I think this would be quite difficult with how python-can
works. Maybe let's not go there now and leave it for the future.
from yakut.
If we implemented OpenCyphal/pycyphal#153 then the need for YAKUT_PATH
and yakut compile
will be obviated completely, which is great. Instead of that we will have CYPHALPATH
that points where DSDL sources are, which may default to ~/.cyphal
or something similar depending on the platform.
Then we could have your yakut dsdl install
that would by default download DSDL namespaces to, let's say, ~/.cyphal
or maybe the first location specified in CYPHALPATH
-- we should discuss the specifics later. (EDIT: if ~/.cyphal/uavcan
is missing we could even fetch the namespace from GitHub automatically, does that seem reasonable?)
I suggest we discuss yakut setup
later as well, for now it seems reasonable to focus on automatic DSDL compilation. Let's continue this over at OpenCyphal/pycyphal#153
from yakut.
Related Issues (20)
- Yakut paths are inscrutable and we don't help the user HOT 1
- Yakut default output should use folder HOT 1
- CLI is dumb HOT 2
- Add example for publishing an array type
- Add env command HOT 1
- Add format command HOT 2
- The joystick option installation command needs quotes
- Yakut call should accept multiple node-IDs HOT 1
- Yakut broken on osx HOT 6
- Add AppImage packaging for Yakut HOT 6
- Windows Regression HOT 1
- Provide new installation screencasts
- The installation instructions should mention that the public regulated data types are necessary as well
- For custom commands, allow yakut to read a map file HOT 1
- Monitor: Five-digit node-IDs require a separator
- Add note/link to setup_slcan
- Add an example of how to convert message fields into TSV using jq
- Switch to the latest PyCyphal
- Install Instructions HOT 1
- Compile fails silently with no work is done HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from yakut.