Welcome to the Onshape forum! Ask questions and join in the discussions about everything Onshape.
First time visiting? Here are some places to start:- Looking for a certain topic? Check out the categories filter or use Search (upper right).
- Need support? Ask a question to our Community Support category.
- Please submit support tickets for bugs but you can request improvements in the Product Feedback category.
- Be respectful, on topic and if you see a problem, Flag it.
If you would like to contact our Community Manager personally, feel free to send a private message or an email.
GitHub standard library mirror
javawizard
Member, csevp Posts: 13 ✭✭
Well I got annoyed one too many times at trying to track down when a feature was introduced to the standard library and decided to make an auto-updating mirror of std on GitHub.
And so, without further ado, I present to you.......
https://github.com/javawizard/onshape-std-library-mirror!
It's pretty much what you'd expect: all of the feature studios and blobs in the std doc are mirrored, complete with a commit per published version. The commit dates are accurate so you can do things like blame any of the files and see when exactly each line was changed.
There are two branches:
That's pretty much it! Let me know if you have any requests or thoughts. (It'd be nice to generalize this to sync arbitrary Onshape documents to GitHub, and then add some sort of bidirectional sync as a second step. Maybe next week...)
(Also, since this is bound to be asked by someone: yes this is legal. Onshape's standard library is licensed under the MIT license which permits copying and modifications subject to a few rules which I have of course followed.)
And so, without further ado, I present to you.......
https://github.com/javawizard/onshape-std-library-mirror!
It's pretty much what you'd expect: all of the feature studios and blobs in the std doc are mirrored, complete with a commit per published version. The commit dates are accurate so you can do things like blame any of the files and see when exactly each line was changed.
There are two branches:
- main: an unmodified mirror of the stdlib
- without-versions: all version numbers have been stripped; diffs are much quieter since the stdlib includes version bumps to all import statements in all files every release
That's pretty much it! Let me know if you have any requests or thoughts. (It'd be nice to generalize this to sync arbitrary Onshape documents to GitHub, and then add some sort of bidirectional sync as a second step. Maybe next week...)
(Also, since this is bound to be asked by someone: yes this is legal. Onshape's standard library is licensed under the MIT license which permits copying and modifications subject to a few rules which I have of course followed.)
4
Comments
Lots of secret improvements get added to featurescript that don't make it to the official release notes because they're marked "internal only", this will be a great way to find them.
Experts in Onshape Automation - Custom Features and Integrated Applications
@javawizard not sure if you're still maintaining this repo but the last update appears to not have sync'd to GitHub.
Derek Van Allen | Engineering Consultant | MeddlerIdeally there would be an official GitHub repo from Onshape.
@cody_armstrong @GregBrown
This is really helpful for LLM usage to point an agent at the current Std Library. It also reduces load on the std-library Onshape document.
Simon Gatrall | Product Development, Engineering, Design, Onshape | Ex- IDEO, PCH, Unagi, Carbon | LinkedIn
I haven't been able to get in contact with @javawizard but I believe I understand what is happening: API costs and limits. I've looked in to the onshape std library importer. It is a bash script that polls for changes, then retrieves the std library. The problem is its one api call per feature studio element, and Onshape's std library is chonky: 250+ elements.
Some rough maths:
$.06/api call * 250 calls is about $15
52 weeks / 3 week update cycle is about 17 versions
$15*17 is about 4.2K calls or $250
The script could be more efficient but with Onshape's current api these numbers represent ~minimum cost.
I would love for Onshape to publish its own mirror but if they haven't done it by now it is probably not the way to bet.
Maybe a follow-on question: I don't want to (and probably legally cannot) profit on this but would users be willing to contribute to maintenance costs for this? @Caden_Armstrong @EvanReese @S1mon etc? If we find 17 enthusiasts and each drop $15/yr I could take this over. The other option is to convert this to an app store app (which doesn't charge for api use afaict) but this is subject to Onshape review and see my earlier points about api consumption, git, and onshape.
@jnewth The funny thing is I can probably get Codex to do this through its Browser use skill instead of the API. The API call costs make very little sense to me since some of the things I might want to do with the API I can automate and still do, just in a way that's actually putting more load on the Onshape servers, not less.
Simon Gatrall | Product Development, Engineering, Design, Onshape | Ex- IDEO, PCH, Unagi, Carbon | LinkedIn
That's a great idea @S1mon . I am continually impressed by your leap in to FS and vibe-coding. I don't love this strategy but it does solve the problem and costs a lot less!
I also noticed it has been updated recently. Thanks @javawizard — this is a great resource. See my earlier comment: if it's costing you real money I can toss you a few $$$$$$$$$$$$$$$.