Skip to content

Version 2.x.x

Jump to bottom
jeff edited this page Oct 6, 2023 · 1 revision

SolidPython 2.x.x is a refactored version of SolidPython 1.x.x. The refactoring process was based on the following proposal: https://github.com/SolidCode/SolidPython/issues/169

The goal was to

  • extract the "core" from SolidPython
  • make a solid package that only contains the fundamentals (+ a few convenience features)
  • make it extendible
  • try to get complex libraries working properly (mcad, bosl, bosl2)
  • KISS: from solid2 import * -> imports only ~1000 lines of source code and has (almost?) all the feautres SolidPython 1.x.x has
  • be a drop in replacement for SolidPython 1.x.x -- as far as possible, see Backwards Compatibility Section
  • get all kinds of nice features working (see Features section)

The result is a refactored and in some parts rewritten version of SolidPython we would like to release as SolidPython 2.x.x. The major improvement is a code base that should be better maintainable and extendible.

Besides these benefits SolidPython 2.x.x implemented quite a few nice new features (cf. Features section).

Features

SolidPython 2.x.x has support for the following new features:

Furthermore it has several minor improvements, like these which are based on ideas from posts from the SolidPython universe:

  • use invert operator (~) as # in OpenSCAD #167
  • convenience function including to pass sizes as integer parameters (translate(10, 20, 30)) #63
  • access-style syntax: cube(1).up(5).rotate(45, 0, 0) #66 This is additional! The OpenSCAD / SolidPython style syntax is still fully supported.

Another nice little feature especially to play around and debug it is that the __repr__ operator of each "OpenSCADObject" now calls scad_render. With this the python shell becomes pretty good in debuging and playing around with solid code and the library itself:

>>> from solid2 import *
>>> c = cube(5)
>>> c.up(5)
translate(v = [0, 0, 5]) {
        cube(size = 5);
};
>>> c.up(5).save_as_scad()
'/home/xxx/xxx/xxx/SolidPython/expsolid_out.scad'
>>>

Backwards compatibility

SolidPython 2.x.x should be a complete and mostly backwards compatible drop in replacement for SolidPython 1.x.x. The backwards compatibility is not 100% as depicted by the version number. Somethings (and even interfaces) changed. We tried to stay as backward compatible as possible. The package should behave 98% the same as SolidPython unless you do some "deep access" -- that's by 99% chance not backwards compatible (like modifying OpenSCADObjects or import internal modules).

As long as you stick to:

from solid2 import *

you shoul be fine.

solid.utils

solid.utils consisted of convenience functions and "modelling extensions" (kind of a small third party library like mcad, bosl, bosl2). The convenience functions are now -- or the missing ones are supposed to be -- part of solid2.extensions.convenience and are automatically importet with the main package.

Concerning the "modelling extensions" I would actually like to get rid of them as part of the SolidPython 2.x.x package. The resons are the following:

And a looooot more.....

I don't see why SolidPython should implement and maintain its own set of these features. Furthermore I assume a third party library (like bosl2) is probably able to provide more sophisticated implementations than we will ever be able to provide.

Please take a look at the bosl2 implementations. I did some very basic tests in examples/07-libs-bosl2.py and -- at least -- was able to create basic examples for the core solid.utils features using bosl2.

I would also be fine with a python third party library that implements these features, but I would like to seperate it from SolidPython itself. The reason is to achieve a SolidPython module which is independent from it (development, bugs, maintainance) with the goal to get an as solid and stable as possible SolidPython (core) package.

BUT, since I assume quite a few people out there are using solid.utils up until now and simply getting rid of it might cause some brouhaha, my suggestion for a compromise is the solid_legay extension.

solid2_legacy

The solid2_legacy extension is basicly everything that used to be solid.utils. Furhtermore it tries to "mimic" the SolidPython 1.x.x interface. This is the effort to become as backward compatible as possible. This might for example be useful when trying to get existing SolidPython 1.x.x code running.

The solid2_legacy extension got extracted into a seperate repo (and pip package). You should be able to just import the package if it is installed or somewhere in your import path.

If you want to use those features import the extension and take a look at it.

from solid2_legacy import *

Anyway SolidPython 1.x.x imports do not work with SolidPython 2.x.x! (see Interface changes - imoprt paths have changed)

I was able to get the SolidPython 1.x.x examples running just by changing the imports and they all (except for the splines example which seems to have an internal issue) worked "out of the box".

Interface changes

  • OpenSCAD identifier escaping:
    • all illegal python idetifiers are escape with a single prepending underscore
    • special variables $fn -> _fn (note: segments still works)
    • identifier starting with a digit module 12ptStar() -> _12ptStar() (note: __12ptStar still works)
    • python keywords module import() -> _import() (note: import\_ still works)
  • import paths have changed (a lot)
    • as long as you only import the root package it should be fine, otherwise probably not
    from solid2 import * #fine
from solid2 import objects #crash
from solid2 import solidpython #crash
from solid2 import splines #crash
from solid2 import utils #crash
  • all extensions have been moved:
    • solid.utils has been moved to solid2_legacy. If you want to use them import that extension
    • there are some example implementations of the part / hole feature and bill of materials in solid2_legacy. They seem to work but are not tested extensively. Take a look at examples/xx_legacy*.
    • please take a look at the bosl2 example. BOSL2 provides many features which might be alternatives.
  • OpenSCADObject internally changed a lot

    If you access it directly (e.g. mycube.set_modifier) this might not work. But if you import solid2_legacy some dummy methods will be monkey patched onto OpenSCADObject so you might be able to at least run the code, but it might render not correctly.

  • maybe some more things I can't remember. Some function signatures changed slightly. But as long as as you stick to the regular public interface everything should be fine.

Clone this wiki locally