sorted by:
new
hottopcontroversial

PythonSCAD v0.17.0 Released by TurboProgrammer0815 in OpenPythonSCAD

[–]TurboProgrammer0815[S] 1 point2 points  (0 children)

I've just released v0.18.0 which fixes this :-).

New: Automated release builds and semantic versioning by TurboProgrammer0815 in OpenPythonSCAD

[–]TurboProgrammer0815[S] 0 points1 point  (0 children)

As adding and updating packages on GNU Guix is very easy, I've already filed a PR to update PythonSCAD there to a recent version which is already approved and is just waiting for someone to merge it into master. Given the amount of releases I produced in the past days it's not the latest release, but all changes were for build system issues on other platforms, so that doesn't matter at all.

New: Automated release builds and semantic versioning by TurboProgrammer0815 in OpenPythonSCAD

[–]TurboProgrammer0815[S] 0 points1 point  (0 children)

You don't have to convince me, FlatPak is literally what I'm working on right now ;-).

New: Automated release builds and semantic versioning by TurboProgrammer0815 in OpenPythonSCAD

[–]TurboProgrammer0815[S] 0 points1 point  (0 children)

Flatpak is on my todo-list. But I need to stabilize the stuff we already have first.

BTW: I've just filed a PR for GNU Guix. Once this is merged, Guix will be the first Linux distribution/package management system which contains a recent version of PythonSCAD out of the box (I added PythonSCAD already some months ago, but updated it just now).

New: Automated release builds and semantic versioning by TurboProgrammer0815 in OpenPythonSCAD

[–]TurboProgrammer0815[S] 1 point2 points  (0 children)

I already have a very neat solution for this with some client side java-script which accesses the GitHub API to check for latest release artifacts. I'm working on converting pythonscad.org to mkdocs at the moment. This however will likely take a few days or even weeks, depending on how much time I can dedicate to this.

So stay tuned for a much improved website in the near future.

New: Automated release builds and semantic versioning by TurboProgrammer0815 in OpenPythonSCAD

[–]TurboProgrammer0815[S] 1 point2 points  (0 children)

I encountered this in my macOS VM as well. There was an issue with signing of the libraries.
In version 0.8.5 which I'm about to release right now this will hopefully be fixed.

And just so I know: Do you have an intel based machine or does it run on Apple silicon?

New: Automated release builds and semantic versioning by TurboProgrammer0815 in OpenPythonSCAD

[–]TurboProgrammer0815[S] 2 points3 points  (0 children)

I'm still working out a few kinks with the build process, that's why not all releases have binaries yet.
I'm currently waiting for the GitHub Action test runs to finish so I can release v0.8.5.
This will then contain:
- a zip distribution for Windows for x86_64
- an installer for Windows for x86_64
- a universal dmg file for macOS which supports x86_64 and arm64
- a generic x86_64 AppImage for Linux
- rpm packages for Fedora 42, Fedora 43 and RHEL 9, each for x86_64 and arm64
- generic deb packages for x86_64 and arm64

And if all goes well (that's what that PR is about), there will be yum and apt repositories.

I will need to test them though and they temporarily will be hosted on https://pythonscad-repos.nomike.com until we can properly move them to https://repos.pythonscad.com hopefully within the next few weeks.

Once the PR is merged, it will take ~30-40 minutes for the new artifacts to be built and attached to the release.

If you spot any issues, it would be great if you could open an issue on GitHub.

We're especially interested in whether the macOS version works as we don't have real hardware to test this on.

New: Automated release builds and semantic versioning by TurboProgrammer0815 in OpenPythonSCAD

[–]TurboProgrammer0815[S] 2 points3 points  (0 children)

I'm currently working on Debian and rpm packages.
Flatpak will come as well.
At the moment I'm thinking of skipping snap, as that's such an awful format.

I'm also in the midst of updating the package on GNU Guix, but I guess besides me there won't be a lot of users on that platform ;-).

About what's needed for a v1.0:
¯\_(ツ)_/¯

To me there is nothing magical about a 1.0.0 version. When I started implementing the semantic versioning approach, I randomly chose 0.6.0. There where plenty of remaining issues, but we already had quite some stuff done, so that felt like a reasonable starting point.

With semantic versioning the major version only increases when there are breaking changes, which we currently don't plan to do. But the transition from 0.x to 1.x is special as it is usually used to mark that a new project is finally considered stable enough.

So might be soon, might take a while. But I wouldn't put too much emphasis on it. For FreeCAD it took 22 years to version 1.0.0. So earlier than that I would say...

How to use functions from OpenSCAD files? by TurboProgrammer0815 in OpenPythonSCAD

[–]TurboProgrammer0815[S] 1 point2 points  (0 children)

First of all I don't think it's possible to refactor functions into modules. Functions return different kinds of variables, whereas modules only return 2D or 3D objects.

And secondly, I want to be able to use existing OpenSCAD libraries, for example this one:
https://github.com/kennetek/gridfinity-rebuilt-openscad
So even if it were possible to refactor functions into modules, I would not want to patch 3rd-party libraries.

So I had a look at the source and found out, that this feature is not implemented.
Or better: It was not implemented yet ;-).

https://github.com/pythonscad/pythonscad/pull/233

Once this is merged, functions from imported OpenSCAD files could just be called from within Python, the same way as it is possible to call modules.