GH
gene heskett
Sun, May 11, 2025 10:08 PM
On 5/11/25 15:31, Torsten Paul via Discuss wrote:
On 10.05.25 03:21, gene heskett via Discuss wrote:
Torsten: While I realize the market size is extremely out of balance
in favor of windows, please do not forget that OpenSCAD is also a
linux application.
Poking the wrong person here :-). I'm running Linux on my personal
systems since Debian 1.3 (bo, 1997), ignoring the even earlier
Slackware from 23 floppy disk dances. So I'm certainly not going to
forget Linux.
While I switched from amigados 3.1 to redhat 5.0 with a stack of
floppy's in late 1998.
But back to the topic of virtual environments. It would be useful
to hear from people who want to use OpenSCAD + Python. What's the
view on this?
I am not a python expert by any definition. I does seem to make a
bulletproof VPN, insulating AppImages from the sometimes ugly vagaries
of the arm64 crowd. And its heavily used for that here. But it it
upchucks, I'm lost.
Right now some official OpenSCAD nightly builds have basic
support for creating a virtual environment that can be used to
install external package for use in OpenSCAD.
(Menu: File -> Python -> Create Virtual Environment ; Select an
empty folder ; Wait for the "Success" popup ; Restart OpenSCAD)
Sounds pretty simple. But I'll likely object if it does not run w/o the
VPN at some point in the future.
Status:
- AppImage: Works for me :-), may have issues on some distros.
AppImages have been bulletproof on bananapi-m5's here, but OpenSCAD not
tested on the pi clones, not (generally) enough fast memory.
- Flatpak: should work wherever the flatpak itself works
I have problems with amd64 flatpaks here, prusaslicer for amd64
switched to flatpak about 6 months back, didn't work here on this 6 core
i5 with 32 GB of memory, and installed over 50,000 files in its home
directory. That is equ to a whole linux install. I deleted it all just
on general principles. Untried on arm64's due to slow u-sd card memory.
- Snap: nope, not working yet, all tries so far failed
FF Works fine on arm64 stuff as a snap. Armbian linux. Jammie or
nobel. Quite stable. Power failure to power failure.
- Distro Packages: untested, probably needs some minor changes
- Windows: nope, no Python yet
- MacOS: nope, no Python yet
ciao,
Torsten.
Thank you for listening, Torsten. Appreciated.
Cheers, Gene Heskett, CET.
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
On 5/11/25 15:31, Torsten Paul via Discuss wrote:
> On 10.05.25 03:21, gene heskett via Discuss wrote:
>> Torsten: While I realize the market size is extremely out of balance
>> in favor of windows, please do not forget that OpenSCAD is also a
>> linux application.
>
> Poking the wrong person here :-). I'm running Linux on my personal
> systems since Debian 1.3 (bo, 1997), ignoring the even earlier
> Slackware from 23 floppy disk dances. So I'm certainly not going to
> forget Linux.
>
While I switched from amigados 3.1 to redhat 5.0 with a stack of
floppy's in late 1998.
> But back to the topic of virtual environments. It would be useful
> to hear from people who want to use OpenSCAD + Python. What's the
> view on this?
I am not a python expert by any definition. I does seem to make a
bulletproof VPN, insulating AppImages from the sometimes ugly vagaries
of the arm64 crowd. And its heavily used for that here. But it it
upchucks, I'm lost.
>
> Right now *some* official OpenSCAD nightly builds have basic
> support for creating a virtual environment that can be used to
> install external package for use in OpenSCAD.
> (Menu: File -> Python -> Create Virtual Environment ; Select an
> empty folder ; Wait for the "Success" popup ; Restart OpenSCAD)
>
Sounds pretty simple. But I'll likely object if it does not run w/o the
VPN at some point in the future.
> Status:
> - AppImage: Works for me :-), may have issues on some distros.
AppImages have been bulletproof on bananapi-m5's here, but OpenSCAD not
tested on the pi clones, not (generally) enough fast memory.
> - Flatpak: *should* work wherever the flatpak itself works
I have problems with amd64 flatpaks here, prusaslicer for amd64
switched to flatpak about 6 months back, didn't work here on this 6 core
i5 with 32 GB of memory, and installed over 50,000 files in its home
directory. That is equ to a whole linux install. I deleted it all just
on general principles. Untried on arm64's due to slow u-sd card memory.
> - Snap: nope, not working yet, all tries so far failed
FF Works fine on arm64 stuff as a snap. Armbian linux. Jammie or
nobel. Quite stable. Power failure to power failure.
> - Distro Packages: untested, probably needs some minor changes
> - Windows: nope, no Python yet
> - MacOS: nope, no Python yet
>
> ciao,
> Torsten.
Thank you for listening, Torsten. Appreciated.
> _______________________________________________
> OpenSCAD mailing list
> To unsubscribe send an email to discuss-leave@lists.openscad.org
> .
Cheers, Gene Heskett, CET.
--
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
- Louis D. Brandeis
CF
Carsten Fuchs
Mon, May 12, 2025 5:22 AM
Hello,
Am 09.05.25 um 22:02 schrieb Torsten Paul via Discuss:
[...]
As far as I'm aware it's the only way that allows people to
be flexible in regard to the python version.
If you use the AppImage, the Python version is fixed in that
build. So for people to use external libraries, those have
to match exactly the python version in the AppImage.
Virtual environments are one solution for that. There may
be others, I'm happy to hear about those. Or if people think
venvs are useless and it's just me thinking they are a must.
I'm with you on venvs. In my experience, venvs are a lightweight and straightforward way to isolate Python "installations" from each other and the OS.
The recently upcoming "uv" tool makes this even simpler (https://github.com/astral-sh/uv), but Python's built-in venv module might as well be sufficient. (I normally just use the version of Python that comes with the OS for python3 -m venv .venv, but if that is outdated, "uv" really saves the day.)
Best regards,
Carsten
--
Dipl.-Inf. Carsten Fuchs
Industriegebiet 3 ℅ Rofu
55768 Hoppstädten-Weiersbach
https://www.cafu.de
Hello,
Am 09.05.25 um 22:02 schrieb Torsten Paul via Discuss:
> [...]
> As far as I'm aware it's the only way that allows people to
> be flexible in regard to the python version.
>
> If you use the AppImage, the Python version is fixed in that
> build. So for people to use external libraries, those have
> to match exactly the python version in the AppImage.
>
> Virtual environments are one solution for that. There may
> be others, I'm happy to hear about those. Or if people think
> venvs are useless and it's just me thinking they are a must.
I'm with you on venvs. In my experience, venvs are a lightweight and straightforward way to isolate Python "installations" from each other and the OS.
The recently upcoming "uv" tool makes this even simpler (https://github.com/astral-sh/uv), but Python's built-in venv module might as well be sufficient. (I normally just use the version of Python that comes with the OS for `python3 -m venv .venv`, but if that is outdated, "uv" really saves the day.)
Best regards,
Carsten
--
Dipl.-Inf. Carsten Fuchs
Industriegebiet 3 ℅ Rofu
55768 Hoppstädten-Weiersbach
https://www.cafu.de
JD
John David
Mon, May 12, 2025 6:24 AM
I've broken out a little time to start playing with PythonSCAD. I'm having
some confusion with how it is discussed online if it is a separate effort,
or now in the most current versions of OpenSCAD. What is the best way to
install/build? In specific, I am still trying to solve the issue of
building colored SVGs, or any other input that is accepted by LaserGRBL or
LightBurn (which I am trying to move away from). @Guenther Sohler
guenther.sohler@gmail.com, last week you posted an image of PythonSCAD
that appears to be from the 2025.05.06 build. Would the same functionality
already be included in the 2025.04.24 code? I got that one already
installed. I tried running the code in your image (that started with "from
openscad import *"), and it failed on the first line. Is there some trick
to starting with python instead of a scad file?
On Mon, May 12, 2025 at 1:22 AM Carsten Fuchs via Discuss <
discuss@lists.openscad.org> wrote:
Hello,
Am 09.05.25 um 22:02 schrieb Torsten Paul via Discuss:
[...]
As far as I'm aware it's the only way that allows people to
be flexible in regard to the python version.
If you use the AppImage, the Python version is fixed in that
build. So for people to use external libraries, those have
to match exactly the python version in the AppImage.
Virtual environments are one solution for that. There may
be others, I'm happy to hear about those. Or if people think
venvs are useless and it's just me thinking they are a must.
I'm with you on venvs. In my experience, venvs are a lightweight and
straightforward way to isolate Python "installations" from each other and
the OS.
The recently upcoming "uv" tool makes this even simpler (
https://github.com/astral-sh/uv), but Python's built-in venv module might
as well be sufficient. (I normally just use the version of Python that
comes with the OS for python3 -m venv .venv, but if that is outdated,
"uv" really saves the day.)
Best regards,
Carsten
--
Dipl.-Inf. Carsten Fuchs
Industriegebiet 3 ℅ Rofu
55768 Hoppstädten-Weiersbach
https://www.cafu.de
OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org
I've broken out a little time to start playing with PythonSCAD. I'm having
some confusion with how it is discussed online if it is a separate effort,
or now in the most current versions of OpenSCAD. What is the best way to
install/build? In specific, I am still trying to solve the issue of
building colored SVGs, or any other input that is accepted by LaserGRBL or
LightBurn (which I am trying to move away from). @Guenther Sohler
<guenther.sohler@gmail.com>, last week you posted an image of PythonSCAD
that appears to be from the 2025.05.06 build. Would the same functionality
already be included in the 2025.04.24 code? I got that one already
installed. I tried running the code in your image (that started with "from
openscad import *"), and it failed on the first line. Is there some trick
to starting with python instead of a scad file?
On Mon, May 12, 2025 at 1:22 AM Carsten Fuchs via Discuss <
discuss@lists.openscad.org> wrote:
> Hello,
>
> Am 09.05.25 um 22:02 schrieb Torsten Paul via Discuss:
> > [...]
> > As far as I'm aware it's the only way that allows people to
> > be flexible in regard to the python version.
> >
> > If you use the AppImage, the Python version is fixed in that
> > build. So for people to use external libraries, those have
> > to match exactly the python version in the AppImage.
> >
> > Virtual environments are one solution for that. There may
> > be others, I'm happy to hear about those. Or if people think
> > venvs are useless and it's just me thinking they are a must.
>
> I'm with you on venvs. In my experience, venvs are a lightweight and
> straightforward way to isolate Python "installations" from each other and
> the OS.
>
> The recently upcoming "uv" tool makes this even simpler (
> https://github.com/astral-sh/uv), but Python's built-in venv module might
> as well be sufficient. (I normally just use the version of Python that
> comes with the OS for `python3 -m venv .venv`, but if that is outdated,
> "uv" really saves the day.)
>
> Best regards,
> Carsten
>
>
> --
> Dipl.-Inf. Carsten Fuchs
> Industriegebiet 3 ℅ Rofu
> 55768 Hoppstädten-Weiersbach
> https://www.cafu.de
> _______________________________________________
> OpenSCAD mailing list
> To unsubscribe send an email to discuss-leave@lists.openscad.org
>
KE
Karl Exler
Mon, May 12, 2025 7:07 AM
ähmm.. for all of us, who are not Prgrammers and who are happy to have
with OpenScad a fine modelling software..... has all this Phyton
"tamtam" any relevance for us ?
yours
Karl
Am 12.05.25 um 08:24 schrieb John David via Discuss:
I've broken out a little time to start playing with PythonSCAD. I'm
having some confusion with how it is discussed online if it is a
separate effort, or now in the most current versions of OpenSCAD.
What is the best way to install/build? In specific, I am still trying
to solve the issue of building colored SVGs, or any other input that
is accepted by LaserGRBL or LightBurn (which I am trying to move away
from). @Guenther Sohler mailto:guenther.sohler@gmail.com, last week
you posted an image of PythonSCAD that appears to be from the
2025.05.06 build. Would the same functionality already be included in
the 2025.04.24 code? I got that one already installed. I tried
running the code in your image (that started with "from openscad
import *"), and it failed on the first line. Is there some trick to
starting with python instead of a scad file?
On Mon, May 12, 2025 at 1:22 AM Carsten Fuchs via Discuss
discuss@lists.openscad.org wrote:
Hello,
Am 09.05.25 um 22:02 schrieb Torsten Paul via Discuss:
[...]
As far as I'm aware it's the only way that allows people to
be flexible in regard to the python version.
If you use the AppImage, the Python version is fixed in that
build. So for people to use external libraries, those have
to match exactly the python version in the AppImage.
Virtual environments are one solution for that. There may
be others, I'm happy to hear about those. Or if people think
venvs are useless and it's just me thinking they are a must.
I'm with you on venvs. In my experience, venvs are a lightweight
and straightforward way to isolate Python "installations" from
each other and the OS.
The recently upcoming "uv" tool makes this even simpler
(https://github.com/astral-sh/uv), but Python's built-in venv
module might as well be sufficient. (I normally just use the
version of Python that comes with the OS for `python3 -m venv
.venv`, but if that is outdated, "uv" really saves the day.)
Best regards,
Carsten
--
Dipl.-Inf. Carsten Fuchs
Industriegebiet 3 ℅ Rofu
55768 Hoppstädten-Weiersbach
https://www.cafu.de
_______________________________________________
OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org
OpenSCAD mailing list
To unsubscribe send an email todiscuss-leave@lists.openscad.org
ähmm.. for all of us, who are not Prgrammers and who are happy to have
with OpenScad a fine modelling software..... has all this Phyton
"tamtam" any relevance for us ?
yours
Karl
Am 12.05.25 um 08:24 schrieb John David via Discuss:
> I've broken out a little time to start playing with PythonSCAD. I'm
> having some confusion with how it is discussed online if it is a
> separate effort, or now in the most current versions of OpenSCAD.
> What is the best way to install/build? In specific, I am still trying
> to solve the issue of building colored SVGs, or any other input that
> is accepted by LaserGRBL or LightBurn (which I am trying to move away
> from). @Guenther Sohler <mailto:guenther.sohler@gmail.com>, last week
> you posted an image of PythonSCAD that appears to be from the
> 2025.05.06 build. Would the same functionality already be included in
> the 2025.04.24 code? I got that one already installed. I tried
> running the code in your image (that started with "from openscad
> import *"), and it failed on the first line. Is there some trick to
> starting with python instead of a scad file?
>
> On Mon, May 12, 2025 at 1:22 AM Carsten Fuchs via Discuss
> <discuss@lists.openscad.org> wrote:
>
> Hello,
>
> Am 09.05.25 um 22:02 schrieb Torsten Paul via Discuss:
> > [...]
> > As far as I'm aware it's the only way that allows people to
> > be flexible in regard to the python version.
> >
> > If you use the AppImage, the Python version is fixed in that
> > build. So for people to use external libraries, those have
> > to match exactly the python version in the AppImage.
> >
> > Virtual environments are one solution for that. There may
> > be others, I'm happy to hear about those. Or if people think
> > venvs are useless and it's just me thinking they are a must.
>
> I'm with you on venvs. In my experience, venvs are a lightweight
> and straightforward way to isolate Python "installations" from
> each other and the OS.
>
> The recently upcoming "uv" tool makes this even simpler
> (https://github.com/astral-sh/uv), but Python's built-in venv
> module might as well be sufficient. (I normally just use the
> version of Python that comes with the OS for `python3 -m venv
> .venv`, but if that is outdated, "uv" really saves the day.)
>
> Best regards,
> Carsten
>
>
> --
> Dipl.-Inf. Carsten Fuchs
> Industriegebiet 3 ℅ Rofu
> 55768 Hoppstädten-Weiersbach
> https://www.cafu.de
> _______________________________________________
> OpenSCAD mailing list
> To unsubscribe send an email to discuss-leave@lists.openscad.org
>
>
> _______________________________________________
> OpenSCAD mailing list
> To unsubscribe send an email todiscuss-leave@lists.openscad.org
MM
Michael Möller
Mon, May 12, 2025 7:09 AM
ähmm.. for all of us, who are not Prgrammers and who are happy to have
with OpenScad a fine modelling software..... has all this Phyton "tamtam"
any relevance for us ?
yours
Karl
Am 12.05.25 um 08:24 schrieb John David via Discuss:
I've broken out a little time to start playing with PythonSCAD. I'm
having some confusion with how it is discussed online if it is a separate
effort, or now in the most current versions of OpenSCAD. What is the best
way to install/build? In specific, I am still trying to solve the issue of
building colored SVGs, or any other input that is accepted by LaserGRBL or
LightBurn (which I am trying to move away from). @Guenther Sohler
guenther.sohler@gmail.com, last week you posted an image of PythonSCAD
that appears to be from the 2025.05.06 build. Would the same functionality
already be included in the 2025.04.24 code? I got that one already
installed. I tried running the code in your image (that started with "from
openscad import *"), and it failed on the first line. Is there some trick
to starting with python instead of a scad file?
On Mon, May 12, 2025 at 1:22 AM Carsten Fuchs via Discuss <
discuss@lists.openscad.org> wrote:
Hello,
Am 09.05.25 um 22:02 schrieb Torsten Paul via Discuss:
[...]
As far as I'm aware it's the only way that allows people to
be flexible in regard to the python version.
If you use the AppImage, the Python version is fixed in that
build. So for people to use external libraries, those have
to match exactly the python version in the AppImage.
Virtual environments are one solution for that. There may
be others, I'm happy to hear about those. Or if people think
venvs are useless and it's just me thinking they are a must.
I'm with you on venvs. In my experience, venvs are a lightweight and
straightforward way to isolate Python "installations" from each other and
the OS.
The recently upcoming "uv" tool makes this even simpler (
https://github.com/astral-sh/uv), but Python's built-in venv module
might as well be sufficient. (I normally just use the version of Python
that comes with the OS for python3 -m venv .venv, but if that is
outdated, "uv" really saves the day.)
Best regards,
Carsten
--
Dipl.-Inf. Carsten Fuchs
Industriegebiet 3 ℅ Rofu
55768 Hoppstädten-Weiersbach
https://www.cafu.de
OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org
+1
man. 12. maj 2025 09.07 skrev Karl Exler via Discuss <
discuss@lists.openscad.org>:
> ähmm.. for all of us, who are not Prgrammers and who are happy to have
> with OpenScad a fine modelling software..... has all this Phyton "tamtam"
> any relevance for us ?
>
> yours
> Karl
> Am 12.05.25 um 08:24 schrieb John David via Discuss:
>
> I've broken out a little time to start playing with PythonSCAD. I'm
> having some confusion with how it is discussed online if it is a separate
> effort, or now in the most current versions of OpenSCAD. What is the best
> way to install/build? In specific, I am still trying to solve the issue of
> building colored SVGs, or any other input that is accepted by LaserGRBL or
> LightBurn (which I am trying to move away from). @Guenther Sohler
> <guenther.sohler@gmail.com>, last week you posted an image of PythonSCAD
> that appears to be from the 2025.05.06 build. Would the same functionality
> already be included in the 2025.04.24 code? I got that one already
> installed. I tried running the code in your image (that started with "from
> openscad import *"), and it failed on the first line. Is there some trick
> to starting with python instead of a scad file?
>
> On Mon, May 12, 2025 at 1:22 AM Carsten Fuchs via Discuss <
> discuss@lists.openscad.org> wrote:
>
>> Hello,
>>
>> Am 09.05.25 um 22:02 schrieb Torsten Paul via Discuss:
>> > [...]
>> > As far as I'm aware it's the only way that allows people to
>> > be flexible in regard to the python version.
>> >
>> > If you use the AppImage, the Python version is fixed in that
>> > build. So for people to use external libraries, those have
>> > to match exactly the python version in the AppImage.
>> >
>> > Virtual environments are one solution for that. There may
>> > be others, I'm happy to hear about those. Or if people think
>> > venvs are useless and it's just me thinking they are a must.
>>
>> I'm with you on venvs. In my experience, venvs are a lightweight and
>> straightforward way to isolate Python "installations" from each other and
>> the OS.
>>
>> The recently upcoming "uv" tool makes this even simpler (
>> https://github.com/astral-sh/uv), but Python's built-in venv module
>> might as well be sufficient. (I normally just use the version of Python
>> that comes with the OS for `python3 -m venv .venv`, but if that is
>> outdated, "uv" really saves the day.)
>>
>> Best regards,
>> Carsten
>>
>>
>> --
>> Dipl.-Inf. Carsten Fuchs
>> Industriegebiet 3 ℅ Rofu
>> 55768 Hoppstädten-Weiersbach
>> https://www.cafu.de
>> _______________________________________________
>> OpenSCAD mailing list
>> To unsubscribe send an email to discuss-leave@lists.openscad.org
>>
>
> _______________________________________________
> OpenSCAD mailing list
> To unsubscribe send an email to discuss-leave@lists.openscad.org
>
> _______________________________________________
> OpenSCAD mailing list
> To unsubscribe send an email to discuss-leave@lists.openscad.org
>
TP
Torsten Paul
Mon, May 12, 2025 8:03 AM
On 12.05.25 09:07, Karl Exler via Discuss wrote:
ähmm.. for all of us, who are not Prgrammers and who are happy to have
with OpenScad a fine modelling software..... has all this Phyton
"tamtam" any relevance for us ?
No, not at all.
From user side it's not much different from the huge number of
existing Python solutions generating OpenSCAD code.
This is just a much better integrated, but optional solution for
those cases.
William very much highlighted the point why I'm supporting this
even though I'm likely to continue using OpenSCAD scripts for my
own models:
Maybe bringing in some more ideas and development that hopefully
can benefit both OpenSCAD scripting and Python use.
ciao,
Torsten.
On 12.05.25 09:07, Karl Exler via Discuss wrote:
> ähmm.. for all of us, who are not Prgrammers and who are happy to have
> with OpenScad a fine modelling software..... has all this Phyton
> "tamtam" any relevance for us ?
No, not at all.
From user side it's not much different from the huge number of
existing Python solutions generating OpenSCAD code.
This is just a much better integrated, but optional solution for
those cases.
William very much highlighted the point why I'm supporting this
even though I'm likely to continue using OpenSCAD scripts for my
own models:
Maybe bringing in some more ideas and development that hopefully
can benefit both OpenSCAD scripting and Python use.
ciao,
Torsten.
JD
John David
Mon, May 12, 2025 8:04 AM
I only have Linux machines. So the Win* install will not be so useful.
I do not have a "python" tab, and saving/running via a .py file is not
working. I'll look at compiling up a newer version. Is there a particular
branch or forked repository I need to work with?
EBo --
On Mon, May 12, 2025 at 3:09 AM Michael Möller via Discuss <
discuss@lists.openscad.org> wrote:
ähmm.. for all of us, who are not Prgrammers and who are happy to have
with OpenScad a fine modelling software..... has all this Phyton "tamtam"
any relevance for us ?
yours
Karl
Am 12.05.25 um 08:24 schrieb John David via Discuss:
I've broken out a little time to start playing with PythonSCAD. I'm
having some confusion with how it is discussed online if it is a separate
effort, or now in the most current versions of OpenSCAD. What is the best
way to install/build? In specific, I am still trying to solve the issue of
building colored SVGs, or any other input that is accepted by LaserGRBL or
LightBurn (which I am trying to move away from). @Guenther Sohler
guenther.sohler@gmail.com, last week you posted an image of PythonSCAD
that appears to be from the 2025.05.06 build. Would the same functionality
already be included in the 2025.04.24 code? I got that one already
installed. I tried running the code in your image (that started with "from
openscad import *"), and it failed on the first line. Is there some trick
to starting with python instead of a scad file?
On Mon, May 12, 2025 at 1:22 AM Carsten Fuchs via Discuss <
discuss@lists.openscad.org> wrote:
Hello,
Am 09.05.25 um 22:02 schrieb Torsten Paul via Discuss:
[...]
As far as I'm aware it's the only way that allows people to
be flexible in regard to the python version.
If you use the AppImage, the Python version is fixed in that
build. So for people to use external libraries, those have
to match exactly the python version in the AppImage.
Virtual environments are one solution for that. There may
be others, I'm happy to hear about those. Or if people think
venvs are useless and it's just me thinking they are a must.
I'm with you on venvs. In my experience, venvs are a lightweight and
straightforward way to isolate Python "installations" from each other and
the OS.
The recently upcoming "uv" tool makes this even simpler (
https://github.com/astral-sh/uv), but Python's built-in venv module
might as well be sufficient. (I normally just use the version of Python
that comes with the OS for python3 -m venv .venv, but if that is
outdated, "uv" really saves the day.)
Best regards,
Carsten
--
Dipl.-Inf. Carsten Fuchs
Industriegebiet 3 ℅ Rofu
55768 Hoppstädten-Weiersbach
https://www.cafu.de
OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org
I only have Linux machines. So the Win* install will not be so useful.
I do not have a "python" tab, and saving/running via a .py file is not
working. I'll look at compiling up a newer version. Is there a particular
branch or forked repository I need to work with?
EBo --
On Mon, May 12, 2025 at 3:09 AM Michael Möller via Discuss <
discuss@lists.openscad.org> wrote:
> +1
>
> man. 12. maj 2025 09.07 skrev Karl Exler via Discuss <
> discuss@lists.openscad.org>:
>
>> ähmm.. for all of us, who are not Prgrammers and who are happy to have
>> with OpenScad a fine modelling software..... has all this Phyton "tamtam"
>> any relevance for us ?
>>
>> yours
>> Karl
>> Am 12.05.25 um 08:24 schrieb John David via Discuss:
>>
>> I've broken out a little time to start playing with PythonSCAD. I'm
>> having some confusion with how it is discussed online if it is a separate
>> effort, or now in the most current versions of OpenSCAD. What is the best
>> way to install/build? In specific, I am still trying to solve the issue of
>> building colored SVGs, or any other input that is accepted by LaserGRBL or
>> LightBurn (which I am trying to move away from). @Guenther Sohler
>> <guenther.sohler@gmail.com>, last week you posted an image of PythonSCAD
>> that appears to be from the 2025.05.06 build. Would the same functionality
>> already be included in the 2025.04.24 code? I got that one already
>> installed. I tried running the code in your image (that started with "from
>> openscad import *"), and it failed on the first line. Is there some trick
>> to starting with python instead of a scad file?
>>
>> On Mon, May 12, 2025 at 1:22 AM Carsten Fuchs via Discuss <
>> discuss@lists.openscad.org> wrote:
>>
>>> Hello,
>>>
>>> Am 09.05.25 um 22:02 schrieb Torsten Paul via Discuss:
>>> > [...]
>>> > As far as I'm aware it's the only way that allows people to
>>> > be flexible in regard to the python version.
>>> >
>>> > If you use the AppImage, the Python version is fixed in that
>>> > build. So for people to use external libraries, those have
>>> > to match exactly the python version in the AppImage.
>>> >
>>> > Virtual environments are one solution for that. There may
>>> > be others, I'm happy to hear about those. Or if people think
>>> > venvs are useless and it's just me thinking they are a must.
>>>
>>> I'm with you on venvs. In my experience, venvs are a lightweight and
>>> straightforward way to isolate Python "installations" from each other and
>>> the OS.
>>>
>>> The recently upcoming "uv" tool makes this even simpler (
>>> https://github.com/astral-sh/uv), but Python's built-in venv module
>>> might as well be sufficient. (I normally just use the version of Python
>>> that comes with the OS for `python3 -m venv .venv`, but if that is
>>> outdated, "uv" really saves the day.)
>>>
>>> Best regards,
>>> Carsten
>>>
>>>
>>> --
>>> Dipl.-Inf. Carsten Fuchs
>>> Industriegebiet 3 ℅ Rofu
>>> 55768 Hoppstädten-Weiersbach
>>> https://www.cafu.de
>>> _______________________________________________
>>> OpenSCAD mailing list
>>> To unsubscribe send an email to discuss-leave@lists.openscad.org
>>>
>>
>> _______________________________________________
>> OpenSCAD mailing list
>> To unsubscribe send an email to discuss-leave@lists.openscad.org
>>
>> _______________________________________________
>> OpenSCAD mailing list
>> To unsubscribe send an email to discuss-leave@lists.openscad.org
>>
> _______________________________________________
> OpenSCAD mailing list
> To unsubscribe send an email to discuss-leave@lists.openscad.org
>
TP
Torsten Paul
Mon, May 12, 2025 8:07 AM
On 12.05.25 10:04, John David via Discuss wrote:
I only have Linux machines. So the Win* install will not be so useful.
I do not have a "python" tab, and saving/running via a .py file is not
working. I'll look at compiling up a newer version. Is there a
particular branch or forked repository I need to work with?
For OpenSCAD master branch, you need to enable Python both on
compile time:
-DENABLE_PYTHON=ON
and on runtime:
CLI: --enable=python-engine --trust-python
GUI: Preferences->Features->Python-Engine
ciao,
Torsten.
On 12.05.25 10:04, John David via Discuss wrote:
> I only have Linux machines. So the Win* install will not be so useful.
>
> I do not have a "python" tab, and saving/running via a .py file is not
> working. I'll look at compiling up a newer version. Is there a
> particular branch or forked repository I need to work with?
For OpenSCAD master branch, you need to enable Python both on
compile time:
-DENABLE_PYTHON=ON
and on runtime:
CLI: --enable=python-engine --trust-python
GUI: Preferences->Features->Python-Engine
ciao,
Torsten.
PK
Peter Kriens
Mon, May 12, 2025 8:29 AM
I am running the snapshot on MacOS:

I can neither see GUI: Preferences->Features->Python-Engine nor can I start the command line with the options CLI: --enable=python-engine --trust-python. I assume the CLI on Mac is in /Applications/OpenSCAD.app/Contents/MacOS/OpenSCAD
Do I need to download another snapshot? I tried to find a landing page for getting started with Openscad python but I am a bit confused.
Kind regards,
Peter Kriens
On 12 May 2025, at 10:07, Torsten Paul via Discuss discuss@lists.openscad.org wrote:
On 12.05.25 10:04, John David via Discuss wrote:
I only have Linux machines. So the Win* install will not be so useful.
I do not have a "python" tab, and saving/running via a .py file is not working. I'll look at compiling up a newer version. Is there a particular branch or forked repository I need to work with?
For OpenSCAD master branch, you need to enable Python both on
compile time:
-DENABLE_PYTHON=ON
and on runtime:
CLI: --enable=python-engine --trust-python
GUI: Preferences->Features->Python-Engine
ciao,
Torsten.
OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org
I am running the snapshot on MacOS:

I can neither see `GUI: Preferences->Features->Python-Engine` nor can I start the command line with the options `CLI: --enable=python-engine --trust-python`. I assume the CLI on Mac is in `/Applications/OpenSCAD.app/Contents/MacOS/OpenSCAD`
Do I need to download another snapshot? I tried to find a landing page for getting started with Openscad python but I am a bit confused.
Kind regards,
Peter Kriens
> On 12 May 2025, at 10:07, Torsten Paul via Discuss <discuss@lists.openscad.org> wrote:
>
> On 12.05.25 10:04, John David via Discuss wrote:
>> I only have Linux machines. So the Win* install will not be so useful.
>> I do not have a "python" tab, and saving/running via a .py file is not working. I'll look at compiling up a newer version. Is there a particular branch or forked repository I need to work with?
>
> For OpenSCAD master branch, you need to enable Python both on
> compile time:
>
> -DENABLE_PYTHON=ON
>
> and on runtime:
>
> CLI: --enable=python-engine --trust-python
>
> GUI: Preferences->Features->Python-Engine
>
> ciao,
> Torsten.
> _______________________________________________
> OpenSCAD mailing list
> To unsubscribe send an email to discuss-leave@lists.openscad.org
TP
Torsten Paul
Mon, May 12, 2025 8:36 AM
On 12.05.25 10:29, Peter Kriens via Discuss wrote:
I am running the snapshot on MacOS:
Quoting myself for the official OpenSCAD nightly build:
Status:
- AppImage: Works for me 🙂, may have issues on some distros
- Flatpak: should work wherever the flatpak itself works
- Snap: nope, not working yet, all tries so far failed
- Distro Packages: untested, probably needs some minor changes
- Windows: nope, no Python yet
- MacOS: nope, no Python yet
Sorry, I don't have the energy to explain the story again,
I'll leave that to Guenter.
I suppose there should be a web page explaining this, I
don't have enough spare time to do all that.
ciao,
Torsten.
On 12.05.25 10:29, Peter Kriens via Discuss wrote:
> I am running the snapshot on MacOS:
Quoting myself for the official OpenSCAD nightly build:
Status:
- AppImage: Works for me 🙂, may have issues on some distros
- Flatpak: *should* work wherever the flatpak itself works
- Snap: nope, not working yet, all tries so far failed
- Distro Packages: untested, probably needs some minor changes
- Windows: nope, no Python yet
- MacOS: nope, no Python yet
Sorry, I don't have the energy to explain the story again,
I'll leave that to Guenter.
I suppose there should be a web page explaining this, I
don't have enough spare time to do all that.
ciao,
Torsten.
