Bring it back to master?

Hi Jeff -
I've been away from SolidPython for a while, but I'm really impressed with the work you've done and it seems like you may have the energy to continue this project. Would you be interested in merging your stable features/refactoring back to master and taking on admin status there? I don't know that I'm looking to disappear entirely from the project, but I've been doing it for a decade and I've got a small kid these days, and it seems like you'd do a great job taking SolidPython forward. Any interest?

Hey Evan,

a couple of thoughts on this topic:

I can imagine to maintain this branch (in terms of mainly bugfixes)
I'm not sure whether I'm gonna invest a lot of time again to carry it further forward from this point on
I don't think merging it with the master branch makes a lot of sense, because the code structure is too far apart
I don't think it's possible to merge (single) features back
I'm not really interested in spending time on packaging, but I might give it a try if necessary
I can imagine to "link" it somehow back to SolidPython-"master"

So the question is what's the path to integrate it back.
The only solution that comes to my head would be kind of a new "major"-Release that switches to this branch in long term and could run in parallel in short term for kind of a beta phase. And I think it would make sense to start of from a blank "project page" because I think at least most of the issues and pull request are resolved in this branch. I don't know how that's possible on GitHub.

What do you think about these thoughts? Any other ideas?

And I think it would make sense to start of from a blank "project page" because I think at least most of the issues and pull request are resolved in this branch. I don't know how that's possible on GitHub.

Ah, is it possible to link issues and pull requests to a certain branch?
If that's the case, we could simply pull this branch into the SolidCode repo and link issues and pull requests either to the master branch or to this branch and run both branches in parallel for a certain time.

These are all valid 'next step' issues, but I think I could remove some or all of the book-keeping difficulties. I'll look at your code a little more, but I think you're right that this branch would replace the current master rather than try to merge into the old codebase. Packaging & release stuff is already set up in the original branch, and I don't think that would cause significant difficulties. Luckily, Poetry makes packaging & releasing much much easier than it used to be in Python.

So - I'm happy to look into some of the fine details; I'm most interested in incorporating your features & fixes, and getting an extra set of eyes on this code as far as maintaining go.

I had a look at poetry and I with you, that's a lot nicer than what I know from a decade ago....

I started forming a beta package, which seems pretty straight forward. The documentation needs some more attention ("merging" the README.rst). And we've got a problem with auto generated docs, because the builtins (which is 90% of the public interface) are generated dynamically and therefor don't even show up when sphinx tries to generate docs..... I don't have any idea what to do about it. Maybe just link to the openscad manual?

Even though I would like to not call it 2.0.0 (and instead 1.2.0), following semantic versioning I think we should call it 2.0.0. Furthermore I think the branch is in a state where it's fine to call it beta state, I think some people did already use it and there where no issues reported yet.....

From my side these are the few things to tackle before bringing it back to SolidPython-"master".

I started to work on the README.rst and packaging stuff:

https://github.com/jeff-dh/SolidPython/tree/master-2.0.0-beta-dev

I would continue to work on the master integration in that branch so I can leave the expSolid branch as kind of a stable branch for now and I have a dev branch for the intetragion.

It's work in progress!

Excellent! As usual, I’m running to catch up.

…

On Sep 30, 2021, at 4:22 AM, jeff-dh ***@***.***> wrote: I started to work on the README.rst and packaging stuff: https://github.com/jeff-dh/SolidPython/tree/master-2.0.0-beta-dev I would continue to work on the master integration in that branch so I can leave the expSolid branch as kind of a stable branch for now and I have a dev branch for the intetragion. It's work in progress! — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android.

So, I spent a little(!) time on the readme. I think it's now at least in a (rough) state where everything crucial is mentioned. I might change it further while we go, but I think for now it has to be good enough.

I would love to somehow get a couple of beta testers give it a shot and see what their feedback is. I think it would be great to do it before releasing it.
Do you see anyway to achieve it? I thought about simply creating an issue in the SolidPython issue tracker assuming that a couple of people are gonna get a notification and might have a look at it, what do you think about it?

I think an issue tracking the branch makes good sense. I don't know anyone who's necessarily invested enough in the project to beta test for us, but it might be worth putting something up on /r/OpenSCAD to see if anyone's interested.

Before we do that though, I wanted to run a couple things by you.

The .openscad and .implicit files that you import to enable all the basic geometry functions is such a graceful way of bootstrapping into the target languages. I'm torn about that particular piece though, because it means that there's no explicit Python library that an IDE or static analyzer can use to know what the right arguments to, e.g. cube() are. In early versions of SP, I autogenerated the OpenSCAD classes, but somebody contributed explicit bindings with docstrings and everything, and that's been helpful to a lot of use using SP, especially once VS Code got better Python support. It's not nearly as graceful a solution as the runtime-analyzed files you've added, but would you be willing to let me incorporate the old explicit code?

I've also been pretty committed to maintaining unit tests for the package and keeping those valid. That's honestly been more work than I'm sure it's worth, but I'm a little nervous to just go without them. I'm not sure exactly where I'd start adding tests with the new format, but would you object to my adding some test infrastructure in a test dir?

All of the (great, clear, nicely numbered!) new example files now don't have a #! /usr/bin/env python line that would let them be self-executable (01-basics.py rather than python3 01-basics.py) and make some adjustments to sys.path that could clash with normal packaging behaviors. Are you committed to that approach? People have strong philosophical feelings for or against self-executing scripts, but I think not altering sys.path is a pretty common best practice these days.

Haha... I knew we where gonna get to this point ;) Let me think about your points for a day or two. I'll come back to it. PS: vim is the one and only :-p

No worries. I'm happy to talk through any of those issues. And it's totally fine at any point if you decide you want to back off and keep going in your own direction. I've been inspired by what you've done so far and I'd understand if you didn't want to dilute it with legacy concerns.

One is easy: I don't mind putting a #!/bin/whatever at the top of the examples. Altering the sys.path is "necessary" to be able to import the solid package from within solid package (the examples directory) unless you have it installed in some other sys.path directory. Since I think it's important to be able to run the examples without having to install solid in a regular sys.path directory I don't see any way around it. I think it's important to be able to run the examples from a github clone without installing it. Furthermore, if you have a stable release installed in .local/lib/python.../site-packages and are working on a development version (or some other copy somewhere on your hard drive) running the examples from within the dev version would import the solid package from .local/lib/ptyon.../site-packages. That's not acceptable for me and the reason why I alter the sys.path. If you have any other solution for that issue let me know.

(you get more quick answers or better questions ;)

The `.openscad` and `.implicit` files that you import to enable all the basic geometry functions is such a graceful way of bootstrapping into the target languages. I'm torn about that particular piece though, because it means that there's no explicit Python library that an IDE or static analyzer can use to know what the right arguments to, e.g. `cube()` are. In early versions of SP, I autogenerated the OpenSCAD classes, but somebody contributed explicit bindings with docstrings and everything, and that's been helpful to a lot of use using SP, especially once VS Code got better Python support. It's not nearly as graceful a solution as the runtime-analyzed files you've added, but would you be willing to let me incorporate the old explicit code?

Do you have a solution how to support ImplicitCAD with the explicit classes? Or would you drop the ImplicitCAD support? I think it's impossible unless you do some harsh compromises.

I hadn't thought about not installing the package. I think that would be an advantage for less technical users.

It sounds like you may prefer not to work with virtual environments? I've found they're the best way to maintain my sanity with lots of different projects and dependencies around. In the virtualenv workflow, you have whatever version of solid installed in your current environment. Changing sys.path explicitly forces the example files to use only the version of solid in the current directory tree. In effect, I think it's saying "I don't care how you have your environment configured, you should use this particular code", and that's why it's frowned on.

I don't feel super strong about ImplicitCAD support. I messed around with it for a bit this spring because the auto-rounding features were nice, but I found it either slow or inaccurate in what it generated. Maybe it would have rewarded some more messing around. Among other things, ImplicitCAD doesn't support polyhedron(), so it was definitely a different way of thinking than some of what I'd been doing in OpenSCAD.

I think that getting IDE support for both OpenSCAD and ImplicitCAD, switched at runtime, would definitely be a nightmare. My priority-- and I understand if that's not your thing-- would be maintaining static analyzability for the core OpenSCAD language. If the ImplicitCAD bindings were dynamically generated like they are now, I think those definitions could be monkeypatched at runtime in a way that would maintain ImplicitCAD support. I'd be happy with that outcome.

I see.... as you might have already noticed I'm not really up to date with the new shiny stuff (IPython, virtual envs, poetry...) and catching up bit by bit. All these topics where quite painfull or not even on the horizon back than when I used to do programming extensively. C++98 and Python 2.6 where still up to date ;) So I'm kinda out dated in some of these topics.... Aaeeh, yeah let me think about it (and maybe have a look at modern virtual envs, what's the easy python way to use them for this issue? Poetry?) But what should be the point about using a different solid version for an example than the one it shipped with? On the otherhand I don't like the sys.path boilerplate code at the top either.....

…

On Fri, 01 Oct 2021 14:37:19 -0700 Evan Jones ***@***.***> wrote: I hadn't thought about not installing the package. I think that would be an advantage for less technical users. It sounds like you may prefer not to work with virtual environments? I've found they're the best way to maintain my sanity with lots of different projects and dependencies around. In the virtualenv workflow, you have whatever version of `solid` installed in your current environment. Changing `sys.path` explicitly forces the example files to use _only_ the version of `solid` in the current directory tree. In effect, I think it's saying "I don't care how you have your environment configured, you should use this particular code", and that's why it's frowned on.

Just took a look at the BOSL primitives. Before you make any changes, check out the BOSL2 repository. It looks like this commit on 21 September replaced the primitives.scad file with calls to shapes2d.scad or shapes3d.scad.

Could you have a look at the current head of master-dev.... branch and check if code completion / static analyzers are working with it?

For now it's just a hack using the explicit classes from SolidPython master and conditionally(!) importing them. I don't know whether the static analyzers can handle it but if it works we would not have to drop the Implicit support.

IPython seems to handle it correctly. There's another problem in the convenience module at the moment for square and cube, I'm gonna have a look at it, but otherwise it seems to work, so I guess we can get BOSL2 primitives + implicit support.

Just to let you know, I didn't had any time to work on it yet and there will probably be no time for it in the next couple of weeks.

It's not canceled but might take some time.....

Btw: the issues you mentioned I think are all "fixed" in the current head. But the switch from OpenSCAD to BOSL2 primitives is not done and I think this should be done with care to get it right and from a - z to get a clean integration.

All good! My whole family got super sick this week (not COVID, but close enough!) and I haven’t looked at the branch since last week either. It sounded like the changes you made got us most of the way there already. I’ll be back in touch when we’re healthy again and I’ve spent some time with the branch you’ve got. Thanks for all the good work

…

On Oct 10, 2021, at 3:10 PM, jeff-dh ***@***.***> wrote: Btw: the issues you mentioned I think are all "fixed" in the current head. But the switch from OpenSCAD to BOSL2 primitives is not done and I think this should be done with care to get it right and from a - z to get a clean integration. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android.

So, after spending some time recently again thinking and working on SolidPython / exp_solid, I decided that I don't want to replace the OpenSCAD primitives with the BOSL2 primitives. I'm afraid that could cause issues in some use cases and could cause quite some more work and / or would be a (too) drastic change.

There for I would propose that if we want to bring this branch back to master, this is probably the state we should take.

I spent a few hours on the bosl2 topic with the following results:

I updated and improved the bosl2 extension. It's now self contained in the solid package.

We should not replace the builtins with the bosl2 builtins, because for example bosl2.cube does not have the parameter center where as the default OpenSCAD builtin cube has that parameter. This would not be backwards compatible and I guess would cause trouble.

Buuut using SolidPython with bosl2 support is this easy:

from solid.extensions.bosl2 import *
    diff() (
        cuboid(50) (
            sphere(d=40).attach(TOP).tag("remove"),
            cylinder(h=40, d=10).attach(CTR).tag("keep")
        )
    )

So I don't plan to make any major changes anymore.

Are you still interested to "Bring it back to master"?

Btw: I wondering whether it would make sense to release this as "solid2" package or similar. What do you think about it? Because it will break code. It's not 100% backwards compatible.

Hi Jeff- Sorry for the delay. I am still interested in folding in your minimalist approach to SolidPython, although as you can see I've been distracted in other directions this last year.

I agree about separating the BOSL2 primitives from the OpenSCAD primitives; there's enough difference between them that I think it would be more confusing to users to have them combined rather than separate.

I'd be happy with a solid2 package if you think that backwards compatibility would cause too much compromise with new features. At this point I think I've probably dragged my feet too long and I should just hand over the keys to you rather than slowing things down.

I finally published (some beta) solidpython2 package.....

pip install solidpython2 solidpython2-legacy solidpython2-extensions

https://pypi.org/user/jeff-dh/

@etjones

Soooooo, it seems that SolidPython2 is used be several people out there (https://pepy.tech/project/solidpython2), the feedback is pretty positive and it seems to work (a couple of minor issues where reported but nothing critical from my point of view, the pyright issue is the most "critical" one....).

So I would dare to call this fork "stable & production ready". Furthermore I'm fine with the "infrastructure setup" we have right now.

I was wondering whether you (@etjones ) would mind to place a "reference" to this fork on the SolidPython (master) page. Maybe a note in the Readme? The idea behind it is that people who search for SolidPython or OpenSCAD & Python probably end up at the SolidPython(1) page and if there would be a note in the Readme, they would be informed about this branch and can decide on their own which "version" they'd like to use.

From my point of view this would be the least expensive way to "bring it back to master".

Do you have any thoughts about it?

I think that's great, Jeff. I'll put up a pointer at the top of the README on the SP page this weekend.

And I've been dragging my feet on this for far too long. If we wanted to make your fork the Official SolidPython going forward, what would I have to do? I'm ready to just let it go where the energy is, with no code changes or nagging from me or anything else to get in your way.

If I just say "Hey, this project is deprecated, look at SolidPython2 and install with pip install solidpython2", is that enough? I'd be willing to hand over the keys to the SP1 PyPi package too, but my only concern there is if there are any breaking changes so that if someone using SP1 updated to SP2 their existing code might break.

I just put a note in at the top of the SP1 repo pointing to this repo and to the PyPI page. LMK if there's other information you'd like to get across there.

👍

(I'm fine with the current "solution / setup" and close this ticket, reopen it if you have anything else)

Navigation Menu

Repository navigation

Bring it back to master? #2

7 remaining items

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Bring it back to master? #2

Description

Activity

jeff-dh commented on Sep 27, 2021

jeff-dh commented on Sep 27, 2021

etjones commented on Sep 28, 2021

jeff-dh commented on Sep 29, 2021

jeff-dh commented on Sep 30, 2021

etjones commented on Sep 30, 2021

jeff-dh commented on Oct 1, 2021

etjones commented on Oct 1, 2021

jeff-dh commented on Oct 1, 2021

etjones commented on Oct 1, 2021

jeff-dh commented on Oct 1, 2021

jeff-dh commented on Oct 1, 2021

etjones commented on Oct 1, 2021

etjones commented on Oct 1, 2021

jeff-dh commented on Oct 1, 2021

7 remaining items

etjones commented on Oct 2, 2021

jeff-dh commented on Oct 3, 2021

jeff-dh commented on Oct 3, 2021

jeff-dh commented on Oct 10, 2021

jeff-dh commented on Oct 10, 2021

etjones commented on Oct 10, 2021

jeff-dh commented on Jun 7, 2022

jeff-dh commented on Jun 10, 2022

etjones commented on Jun 20, 2022

jeff-dh commented on Aug 11, 2022

jeff-dh commented on Mar 8, 2023

etjones commented on Mar 10, 2023

etjones commented on Mar 10, 2023

jeff-dh commented on Mar 10, 2023

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions