🐍 PySpeckle 2.0 Discussion!

General
,
#1

Hello all :wave:

I’m sure many of you have tried out the :snake: python client PySpeckle created by the wonderful @TomSvilans and @antoine. We’re starting to think about what shape the 2.0 python client is going to take and would really appreciate your input on this.

Do you have any feedback, pain points, feature requests, etc re 1.0 that we can take on board as we start building 2.0? Any insight on how you’ve been using :pie: PySpeckle 1.0 and how your workflows could be improved upon with changes in 2.0?

Feel free to chime in to the discussion below!

2 Likes
#2

Ping @Speckle_Insider and @Contributors :smile: !

1 Like
#3

One improvement would be to have more straightforward support for all authentication flows. At the moment, you either have to log in with email and password or dive into the innards to set the Auth token (Speckle Blender does this).

I’ll ask around to see if there are any other thoughts - I mention this right off the bat because I was asked about it this morning :slight_smile:

1 Like
PySpeckle authentication
#4

9 posts were split to a new topic: PySpeckle authentication

#13

@dirksliepenbeek you did a few tests with PySpeckle right?

1 Like
#14

Hey guys,

Thanks a lot for the feedback! 2.0 will actually allow you to create personal access tokens (which you can grant specific scopes and specify lifetime) to give your scripts access to your account on your behalf. There should definitely be an easy way in PySpeckle 2.0 to use these directly!

However, on authentication flows: when you get to creating apps that will need to get access to user accounts other than your own, you will need to register your app on your server then go about proper authentication flows through the Speckle Manager . This is to protect account security and give the users of your app the power to grant, view, and revoke permissions. You can read more about authentication in 2.0 in this post @dimitrie wrote .

1 Like
#15

A post was merged into an existing topic: PySpeckle authentication

#16

One area we would like to see improvement is being able to easily create the same objects via the python client as the don’t one e.g. “I’m a structural engineer that wants to create structural beam layouts using python and push them to a Speckle for later consumption by SpeckleGSA”

Currently the kits cannot be shared (I think) so would need to be entirely recreated on the python end.

1 Like
#17

This is partly the reason we’ve started discussing this! Most likely the c# class definitions will act as base schemas, from which we can abstract away and generate types for more languages, including python.

We’re still looking at how to do this best. C# -> JSON Schema -> Other languages currently seems the natural way; but @izzylys will know more. Our Base object should allow for similar behaviours between the two SDKs (which is a bonus point!).

3 Likes
#18

Interested to hear feedback about this! Also, I’m not super familiar with GraphQL yet, and I know that the object/stream/layer way of organizing things is also changing, so let’s discuss how the Python connector should look or “feel” like.

Regarding kits, perhaps what @dimitrie mentions might be an easy way to generate and exchange schemas for Python. I.e. the schemas could be generated from the C# classes and loaded into the Python connector with pydantic or something.

1 Like
#19

Is there any reason why the kits should not just be stored as JSON schemas and loaded at runtime, even for the C# connectors? Then perhaps there is a single source of truth for all connectors?

#20

Yes, several good reasons. The best one is that it’s a layer of indirection that severely bites into dev productivity when actually slaving away over conversion routines. As long as the bread and butter is c#, I want us to be able to be productive and fast there. The other way entails having to change a json schema, then generate classes, then finally see that the field that was added is actually useless because the Revit API doesn’t allow you to set it, only get it.

So for now we’ll need to sticking with c# -> schema -> other language classes.

That’s a good one. There’s several things that I know will be a bit more complicated to implement, namely transports and the whole decomposition api. I’ll exit this discussion and leave the floor to people who actually know how to code python :smiley: