For the record, soon it could be used for implement SolveSpace solver in Blender 2.7x or later

• Plugin for Blender 2.7x KmolYuan/python-solvespace#2

@KmolYuan The "solver" branch exists because of copyright reasons, not for technical ones. If you are aiming for integrating your Python bindings, that should be done in the "master" branch, where active development happens. Are you fine with that?

Sure!

If it can be integrated into the CMake build process it would be better.

By the way, the file file.cpp is using information from SK (Sketch class) of SolveSpaceUI class, It seems to be unrelated to solver parts.

Is possible to separate SK and UI parts, or just using SolveSpaceUI directly to write a *.slvs format?

OK. I will ask you to sign a CLA very soon and then I will be able to integrate your code. I will handle CMake and basic testing for you.

Right now the solver that is exposed via the external interface can only solve for one group, and files have many. So, the exposed solver cannot interact with files. I'm not sure what's the best way to fix this, I've not really considered the binding evolution much.

For the file format section, maybe there should be a new external interface with the internal data format.

Because I want to put the results of the external design process into Solvespace. There would be used as auto-assemble function.

For the file format section, maybe there should be a new external interface with the internal data format.

Unfortunately the way code is currently structured, the internal C++ interface does not check many invariants, so actually exposing it as-is in Python would cause a hard to debug crash in case of misuse. Of course we want to fix that but it is by no means quick.

The UI is not scriptable either.

Thank you for your contribution, and welcome. The SolveSpace project has a Contributor License Agreement; in order for me to be able to merge your changes, please sign it at https://cla-assistant.io/solvespace/solvespace. It will take only a small amount of your time.

@KmolYuan Are you still interested in integrating this?

Python-Solvespace project has been updated a new wrapper mechanism to Cython instead of SWIG at April 2019.

The old SWIG wrapper is terminated at KmolYuan/python-solvespace@24cfed4. They are not existed in the current version.

Wrapper source code:

• Cython/slvs.pxd
• Cython/slvs.pyx

Compile settings:

• Makefile
• requirements.txt (Python dependence)
• setup.py
• .travis.yml
• appveyor.yml
• platform/patch.diff (for Python compiler option update)

For development:

• __init__.py (module expose for Python code)
• slvs.pyi (stub file)
• test_slvs.py (unit test)
• example/*.slvs (cases in unit test)

The makefile is just used to call "python setup.py build_ext -j0 --inplace" and clean them up (non-essential). In the current test, Python-Solvespace can be coexist with Solvespace.

To merge them, there must be some work here:

• Move above source code into Cython directory.
• The setup.py file needs to adjust as https://packaging.python.org/tutorials/packaging-projects/.
• Integrate CI tests.

Directory is as follows:

/solvespace
    /cython
        /python_solvespace
            __init__.py
            slvs.pyi
            slvs.pxd
            slvs.pyx
        /platform
            patch.diff
        /tests
            __init__.py
            test_slvs.py
        setup.py
    ...

Looks reasonable.

There are two different ways to add this solver wrapper.

Let solvespace as submodule in python-solvespace; or integrate the wrapper into the branch (or maybe new branch) of solvespace, then python-solvespace might be deprecated.

I think the former will be more convenience to publish the wrapper to PyPI with CI service. The submodule can follow master branch if Solvespace updated. I can do some testing first.

If the latter one, the wrapper packages still can released at a forked repository.

@whitequark Which way does this community prefer?

So, there's one thing to discuss first. SolveSpace uses the GPLv3+ license and has a CLA. Are you willing to relicense the wrapper as GPLv3+ and sign the CLA? If no, the bindings unfortunately have to be separate. If yes, then I propose putting the bindings in the same repository, so that they will always be tested with the most recent SolveSpace version, and distributed together.

OK, I will change the license of python-solvespace to GPLv3+.

I will fork this repository and do it at python branch as above plan.

The PyPI releases require user account and password from CI serves. In common way, the user name and password are stored in TWINE_USERNAME and TWINE_PASSWORD environment variables of Twine.

Travis CI (Ubuntu):

matrix:
    include:

        - os: linux
          sudo: required
          python: "3.6"
          dist: xenial
          deploy: &deploy-options
              provider: pypi
              user: $TWINE_USERNAME
              password: $TWINE_PASSWORD
              skip_cleanup: true
              skip_existing: true
              on:
                  tags: true

        - os: linux
          sudo: required
          python: "3.7"
          dist: xenial
          deploy:
              <<: *deploy-options

Travis CI (Mac OS):

after_success:
    - if [[ "$TRAVIS_OS_NAME" == "osx" ]]; then
        if [ -n "$TRAVIS_TAG" ]; then
            python3 -m pip install twine --user;
            python3 setup.py sdist bdist_wheel;
            python3 -m twine upload dist/*.whl --skip-existing;
        fi
        fi

AppVeyor (Windows):

artifacts:
    - path: dist\*.whl

deploy_script:
    - IF "%APPVEYOR_REPO_TAG%"=="true" (pip install twine)
         ELSE (echo deployment has been skipped as environment variable has not matched)
    - IF "%APPVEYOR_REPO_TAG%"=="true" (twine upload dist\*.whl --skip-existing)

Here are some things to do:

• Change path of package.
• PyPI account of solvespace (and contributors).
• When to release? (by tags?)

@KmolYuan Thanks for preparing this. I'll look into it closer shortly.

Hello! I have published the wrapper named as python-solvespace on PyPI (under GPLv3+).

pip install python-solvespace

The CI / CD configurations are modified with "matrix" mechanism (Travis / AppVeyor). And I keep the old deployments on solvespace/solvespace, PyPI deployments on KmolYuan/solvespace.

I hope you guys can check them out if I do something wrong. Then I will open a pull request.

• .travis.yml
• appveyor.yml

The distributions are supported with Windows (3.6, 3.7) and mac OS (3.6, 3.7, 3.8-dev), Linux user needs to build from source.

The package version 3.0.0 is depend on C++ kernel just like PyQt, the major and minor version are same, the micro version will changed with wrapper updating.

Hello! I have published the wrapper named as python-solvespace on PyPI

Awesome!

But check "Project description" on PyPI website - seems like its markup is broken! (does PyPI support Markdown markup?)

@Symbian9 Oh, that's an upstream issue that PyPI can't update description unless release a new version.
(I forgot to set text/Markdown first time.)

Maybe I can publish 3.0.0.post0 to fix this.

Oh! I made a big mistake with Linux sources.

The upper directories and files needs to move into python_solvespace folder, otherwise they will excluded by sdist (packing sources) command. I will fix them in a while.

OK, I solved it by copy ../src and ../include to python_solvespace temporarily before building the libraries or packing the sources.

https://github.com/KmolYuan/solvespace/blob/python/cython/setup.py#L99-L112

I am sorry but it's not clear. @KmolYuan, will you sign the CLA and merge the wrapper?

@igorkb Yes, I have signed. Python wrapper is at a stable version 3.0.3.post1 currently.

I can open a new PR if there comes another release. (maybe after a long time maintenance)

#493

Hi @KmolYuan have you noticed that one more person seems to have started/done a Python wrapper here?
https://github.com/realthunder/solvespace/commits/python
It is quite out of date with master and I have not looked at the code (I do not know Python) but perhaps you and @realthunder could join forces. Or you could look at his for for useful pieces/ideas.

@ruevs Well, that wrapper is made by SWIG, which needs to write an interface file and compile it together.
This version uses CMake to complete the compilation process.

My early attempts did the same.
But because it is not easy to maintain the Python port, this solution was abandoned.
The advantage of Cython is that the syntax is similar to Python, and it is easier to expand Python's functions (such as docstring).

The tricky thing is Cython sources can not compile directly with CMake. Maybe something like scikit-build?

In order to support assembly, the libslvs API needs to be extended. You can reference my patch here. Although it is based on an older version, it should still be relevant.

Some other useful patches, which may or may not be relevant any more,

• Allow raising exception instead of abort on invalid input, (realthunder@b7c390d)
• Expr memory optimization, as the original implementation for Linux is very inefficient (realthunder@1a38896)

@realthunder I think those changes your pointed out would be really good to have in SolveSpace!
Would you consider making seperate PR's for those?
If not, would you mind if I would bring them over?

Has anyone ever considered making a (C++) Class that contains the solver only?
I imagine that would reduce duplication when making multiple bindings, I got this feeling because embind and boost.python seems to be pretty simple when using a Class.

@vespakoen I don't think I have time for making a PR here. You are of course welcome to use my code.

Awesome News for Blender users!

Thanks to @hlorus, now there is "Geometry Sketcher" add-on for Blender 2.92+ (written on top of @realthunder's py_slvs Python module) for adding SolveSpace 2D geometry constraints into Blender!

• Blender Add-On: https://github.com/hlorus/geometry_sketcher
• Screenshots:
  • https://twitter.com/hlorus1/status/1434186997514522629
  • https://twitter.com/PaoloFurani/status/1439311194037305344
• Demo Video:
  • https://twitter.com/hlorus1/status/1434187037800902658
  • https://twitter.com/hlorus1/status/1438913270098939904

N.B. This add-on implementation finally closes (partially) my old request to @KmolYuan:

• Plugin for Blender 2.7x KmolYuan/python-solvespace#2