Managing a FeatureScript Library

sam_parsons

Hey guys,

We've spent the last year building a great set of custom features for our joinery company. But as the library grows, we're finding it difficult to keep on top of feature updates.

We're splitting out bits of FeatureScript into functions that can be reused in different features, but then you have the issue of needing to update those if they're not within the same document as the feature.

We've thought about putting all of our custom features and functions within the same document, but then there's the scary hurdle of having to reapply those features in the feature list of all the models they're already used in.

Wondered if anyone out there had experienced something similar and had any suggestions?

Sam

TimRice

I would strongly suggest keeping the features all in separate documents. That way you can properly manage the versions without unnecessarily up-versioning features that didnt change.

sam_parsons

I take your point.

Based on that, might you suggest that we kept functions that we use in the same document as a kind of internal utility library? And then import those where needed into custom features which are in their own document, which may even mean that some custom features simply execute a function from the 'global functions' document and not much more than that. But then at least the custom feature is defined in its own document... ?

It's just that sometimes, it feels like it would be easier if our custom features just updated the way onshape's native features do when onshape releases a new version. Though I do understand why that isn't the case.

TimRice

I apologize if I am misunderstanding, but why would you need to keep the features in one doc as a library? Personally, I keep all of my features in a folder on the docs page. Generally I would avoid duplicating references as this goes against our "single source of truth" paradigm. 

In our Enterprise level we do support admins setting a default company wide FS toolset and manage the referenced version for each feature.

john_mcclary

I used to keep all my featurescripts in one doc, but it got very annoying every time I tweak one of tte scripts every document i own and every part studio had a blue update icon, because there was at least one feature i was using from the document. Even though that feature was not the updated one. 

Also if others use your features then they too will be annoyed by this even if the features they use are not the one you update.

Remember versions are document wide.

Eventually i ended up breaking up everything into new documents. And store those documents into a featurescripts folder that i manage as a library. Much smoother 

sam_parsons

It's actually precisely for the single source of truth that we're splitting some stuff out of custom features. We're not duplicating anything, only referencing/importing.

There a certain bits of script that we end up putting across multiple custom features (like enums or functions), which, when updated, would have copied and pasted in. It seems a lot more sensible to import them in, but the question, I suppose, is from where? If those functions are in featurescript studios in the same file as a custom feature, then they aren't in the other custom features where it is used, hence the suggestion for a function library (not dissimilar to the onshape's standard library source).

Does that make sense?

sam_parsons

john_mcclary said:

Eventually i ended up breaking up everything into new documents. And store those documents into a featurescripts folder that i manage as a library. Much smoother 

Hi John, that's what we've got at the moment, there's just a lot of overlap with some of the custom features. I definitely see logic in keeping the features themselves separate though

sam_parsons

TimRice said:

In our Enterprise level we do support admins setting a default company wide FS toolset and manage the referenced version for each feature.

Interesting... anywhere I can preview that functionality....?

john_mcclary

I see your problem. 

How big of a cross reference spider web is it?

I still think it is ok to have a couple of features in the same document if they are part of the same suite of tools that all need to update together anyway 

sam_parsons

It's a tricky one, because just when you think they don't overlap, you find some overlap....

john_mcclary

I guess the next question would be,

How important is it that they all reference each other?

Maybe some things are better off disconnected 

TimRice

sam_parsons said:

TimRice said:

In our Enterprise level we do support admins setting a default company wide FS toolset and manage the referenced version for each feature.

Interesting... anywhere I can preview that functionality....?

Please see our Whats new update for OCTOBER 17TH, 2019: https://forum.onshape.com/discussion/12473/improvements-to-onshape-october-17th-2019/p1 

sam_parsons

TimRice said:

Please see our Whats new update for OCTOBER 17TH, 2019: https://forum.onshape.com/discussion/12473/improvements-to-onshape-october-17th-2019/p1 

Thanks Tim! It looks like that would be useful for making sure the team's toolbar is up to date. But doesn't necessarily help us when it comes to managing the code and feature studios.

john_mcclary said:

I guess the next question would be,

How important is it that they all reference each other?

Maybe some things are better off disconnected 

You're right John, not all of them need connecting, and it might need to be determined on a case by case basis.

Just wanted to see what other onshape users were doing with repeated FS code.