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.
working with import versions in FS
adamohern
Member, OS Professional Posts: 216 PRO
I understand the need for tight version controls in FS, and I'm really glad we have the ability to specify a specific version of FS for each script we write. It's going to be really great for stability and reliability.
That said, it's a real humbug to work with in practice. Not only do I have to manually update the version to some arbitrary number every time FS is updated--potentially as often as every three weeks--but if I update one file and forget to update the files it imports, suddenly there are version mis-match errors I have to diagnose. Not only that, but each FS contains two redundant references to the current version of FS: the one in the shebang, and the one in the geometry.fs import. If you change one but forget to change the other, you're in errorville.
The worst, actually, is importing my own tabs, each of which has its own 24 character version. If I make a little tweak in one of those imported tabs, I must then go to every tab that imports it and update the version before seeing if the code actually works. This is a major buzz kill.
So what to do? I like the stability and reliability of explicit versioning, but I also really (really) dislike having to constantly manually update my versions.
I know you may really hate this idea, but I would be grateful if the version parameter accepted "latest" as an argument. I know, I know... that will result in things breaking sometimes. That's a price I'd be willing to pay during development. Once development is done, I can then replace those "latest" flags with actual concrete versions, thereby locking things down for the long haul.
Thoughts on this? My code is getting too big to keep in one FS tab, so I really want to break my code into imported modules. I can't do that with the current system, as the version management overhead (as I understand it) is too onerous.
That said, it's a real humbug to work with in practice. Not only do I have to manually update the version to some arbitrary number every time FS is updated--potentially as often as every three weeks--but if I update one file and forget to update the files it imports, suddenly there are version mis-match errors I have to diagnose. Not only that, but each FS contains two redundant references to the current version of FS: the one in the shebang, and the one in the geometry.fs import. If you change one but forget to change the other, you're in errorville.
The worst, actually, is importing my own tabs, each of which has its own 24 character version. If I make a little tweak in one of those imported tabs, I must then go to every tab that imports it and update the version before seeing if the code actually works. This is a major buzz kill.
So what to do? I like the stability and reliability of explicit versioning, but I also really (really) dislike having to constantly manually update my versions.
I know you may really hate this idea, but I would be grateful if the version parameter accepted "latest" as an argument. I know, I know... that will result in things breaking sometimes. That's a price I'd be willing to pay during development. Once development is done, I can then replace those "latest" flags with actual concrete versions, thereby locking things down for the long haul.
Thoughts on this? My code is getting too big to keep in one FS tab, so I really want to break my code into imported modules. I can't do that with the current system, as the version management overhead (as I understand it) is too onerous.
1
Comments
You only need to manually update versions of things you import from outside the document -- and we have work planned for tools to make this easier. I also don't think there's an urgent need to always update to the latest version of std -- old versions will continue to work just fine in perpetuity.
1) It may just be lag on my side (the FS editor is very laggy on my internet connection, often taking five to ten seconds to recognize changes, update suggested code, update warnings and errors, etc), but I was having problems with saving code changes in on FS and not seeing the updates until I commit any and every FS that imports it. Let's say I have one FS tab called "ExtrudeSomeStuff" and another called "BooleanSomeExtrudes" that imports it. I have a Part Studio that implements the "BooleanSomeExtrudes" script. In this scenario, changing the "ExtrudeSomeStuff" code is not reflected in the Part Studio until I go back to the boolean script, make an arbitrary change, and commit.
2) It's true that you don't technically need to update the FS version with each new version of std... unless you're importing things. What happened in my case was that I wanted to break some of my code out into an external tab and then import it back into my script. When I did so, the new tab was on the latest version of FS, but the old one was on the previous version. When I tried to import it, I was thrown an error because FS cannot import code from a newer version. To fix the problem I had to manually update the FS version of the old script to match that of the new one before being able to import it. Yes, it's doable. It's also annoying.
Anyway, as I said above, if it's meant to work this way, fine. I'll just keep working with it and hope things become clearer over time.