<ali1234>
i don't think that's a venv, that's just installing into the system path (after mangling it?)
<teepee>
nope, debian does not allow install into system path
<teepee>
also thats as user
<teepee>
and list only shows pip, nothing else
<ali1234>
if you had a venv, you'd have a pip binary you could run outside openscad
<teepee>
sure, I have that
<ali1234>
what happens when you run it? which version of python does it invoke?
<teepee>
it's running the native python exe as pip
<teepee>
all system, as that's locally build
<ali1234>
so you can't package it...
<teepee>
no, not in that state
<ali1234>
someone on #python suggested another solution:
<teepee>
for that it needs to be able to call the openscad binary as pip
<ali1234>
instead of hacking openscad to behave like python, ship the real python.exe and a python script that checks argv[0] and then shells out the the right binary
<ali1234>
that should be much simpler
<teepee>
for some stuff yes, I can see some cases that would be more complicated
<teepee>
we'll see, one step at the time
<teepee>
sys.prefix = /tmp/venv-1
<teepee>
sys.base_prefix = /usr
<teepee>
"When a Python interpreter is running from a virtual environment, sys.prefix and sys.exec_prefix point to the directories of the virtual environment, whereas sys.base_prefix and sys.base_exec_prefix point to those of the base Python used to create the environment. It is sufficient to check sys.prefix != sys.base_prefix to determine if the current interpreter is running from a virtual environment."
<teepee>
by that definition it does see a venv
<ali1234>
hmm... i suppose it does
<teepee>
I have no idea *how* it picks up the venv though, that's slightly worrying
<ali1234>
you're supposed to activate it ("source venv/bin/activate")
<ali1234>
this sets environmental variables that the normal interpreter picks up
<teepee>
I know and interestingly VIRTUAL_ENV does not matter
<teepee>
PATH is actually used which is odd
<teepee>
as my executable is openscad-nightly and not python or python
<gbruno>
[github] andyDoucette opened issue #5721 (DEPRECATED: Using ranges of the form [begin:end] with begin value greater than the end value is deprecated...) https://github.com/openscad/openscad/issues/5721
<gbruno>
[github] andyDoucette edited issue #5721 (DEPRECATED: Using ranges of the form [begin:end] with begin value greater than the end value is deprecated...) https://github.com/openscad/openscad/issues/5721
guso78k has quit [Ping timeout: 240 seconds]
<gbruno>
[github] andyDoucette edited issue #5721 (DEPRECATED: Using ranges of the form [begin:end] with begin value greater than the end value is deprecated...) https://github.com/openscad/openscad/issues/5721
<gbruno>
[github] andyDoucette edited issue #5721 (DEPRECATED: Using ranges of the form [begin:end] with begin value greater than the end value is deprecated...) https://github.com/openscad/openscad/issues/5721
<guso78k>
its not about nimport. i want to show the idea to have a python "reiter"
<guso78k>
i have seen that you added python "Settings
<teepee>
sure, why not, if we have configuration stuff, a separate section makes sense. especially with the build switch
mmu_man has quit [Ping timeout: 265 seconds]
<guso78k>
nimport is same as python import., but with url instead of packet name
<stealth_>
what is it you guys trying to do?
<teepee>
I'm trying to enable python venvs in openscad, as that's the only way for some of the packaging formats to support python packages
<stealth_>
cool, what bout the link above
<stealth_>
its better to install from github vs download the .py file off the net(at least it seems like that to me). e.g `python3 -m pip install git+https://github.com/.../`
<stealth_>
well... I will assume you know what you are doing :p I am not a C coder.
<stealth_>
I thought it would be in python for some reason!
<teepee>
most of it is in python, but that's standard stuff, from the core python distribution
<stealth_>
Yeah, I normally use Cython for stuff like that.
<guso78k>
Cython is good for speeding up existing python code. But in this bare python cannot do solids, so nothing to improve
<guso78k>
my openscad pip module is basically only the compile stage. It completely misses the configure/cmake state to adapt to target system
<stealth_>
Yeah, It would have been good if I actually learned C but I didn't want to learn it.
<guso78k>
it was almost best decision for my hobby with computers
<teepee>
OpenSCAD is C++ (mostly) :)
<guso78k>
actually python lowers the percentage ;D
<guso78k>
(and yacc)
<stealth_>
Its not a bad choice, just C gives me the creeps... I don't really mind the syntax that much, maybe since I come from Python, I like the whole where the bug is fixing is right away, vs C that can be too esoteric
<stealth_>
That being said I am learning Zig, its like C but without all the BS.
teepee_ has joined #openscad
<stealth_>
You guys could probably pick up Zig 2x times faster than me though, since you already have C background.
teepee has quit [Ping timeout: 264 seconds]
teepee_ is now known as teepee
<guso78k>
teepee, how can sombody on github test a pr before merging ?(e.g. graphical stuff is not tested by ctest)
<teepee>
download build, test manually
<guso78k>
ahh, download from the source of the pr. you cannot download the pr itself
<teepee>
sure, you can download the binary
<teepee>
windows/linux-appimage always, macos only if specifically enabled due to build limits
<Scopeuk>
I remember it always being a little funny to get to/find via the github interface
<guso78k>
SchokeUk, in case of teepee's new python venv pr, i could not find the download link
<guso78k>
right new exercising klippers's new features
kintel has joined #openscad
bertronika has quit [Quit: Konversation terminated!]
<kintel>
teepee In terms of lazy unions - did you have a concrete idea what to do about it? Running into som refactoring issues and wonder how much time I should sink into keeping it working properly..
guso78k has quit [Ping timeout: 240 seconds]
<teepee>
pr?
<teepee>
othx: pr is a pull request on github, the associated downloads can be found using this path... https://imgur.com/a/01Z44U1
<teepee>
kintel: I think we should define it to be internal only, e.g. keep the list result but have the upper level responsible to keep the current behavior
<teepee>
for top level, we need some replacement to specify multiple objects. I still think annotations would work for that, but it should be at least explicut
<kintel>
The issue I ran into was that lists can contain mixtures of geometry types (CGAL, Manifold, PolySet, polygon2d), which is a bit annoying to support.
<kintel>
I guess that may still happen for internal usage though, so we might need to solve that in a more general way
<teepee>
I suppose the 2 main cases is "handle separately and pass on as list" and "union all and apply op"
kintel has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
<teepee>
introducing more combinations like 2.5D and allowing mixing those makes it more interesting
kintel has joined #openscad
<kintel>
well, good thing if we remove the top-level, it's no longer experimental :)
<kintel>
Although scrameta's PR will still be
<teepee>
well, not quite, difference() glitches not unioning the objects from the first static slot
<teepee>
difference() {
<teepee>
for (x = [-5, 5]) translate([x, 0, 0]) sphere(5);
<teepee>
cube(10, center = true);
<teepee>
}
<teepee>
I think the data structure needs to be 2 levels, 1st level = static slot, 2nd level list of associated objects