Allow other ways to install cadquery

[rowanG077]

I have had nothing but trouble with conda. Everytime I have to reconfigure my machine I basically have to take a day to get conda working. Is there a possibility to move away from it and just starting using pypi?

[adam-urbanczyk]

I don't think it is realistically an option. Pip does not really support binary depandancies like oce. What is exactly the issue with conda? It works flawlessly on ci so I'm surprised that you are having difficulties with it. Would providing a docker image or a custom anaconda installer help?

[rowanG077]

I think I have installed conda 5 times in total just to use cadquery. Out of those 5 times only once it worked out of the box. One of the times was on windows where it currently still isn't working. On my current OS conda doesn't work at all which means I currently run a Ubuntu VM just to be able to use cadquery. Conda to me is incredibly brittle software so I would really just prefer a normal environment.

[adam-urbanczyk]

@rowanG077 sorry to hear that. If you are willing to share what does not work I could maybe help. I had success following those instructions:
https://docs.anaconda.com/anaconda/install/silent-mode/

[ilya-epifanov]

@adam-urbanczyk The problem with conda is that it pollutes the environment. I just removed it (again) because it was breaking everything else python-related on my machine in very pervert ways.

Docker might be A solution to this. It's should be much easier to use for non-python developers, too.

[rowanG077]

I'm working on getting a nix environment with cadquery and cq-editor going. Don't have it working yet though.

@adam-urbanczyk A docker image would really help I guess. But it just seems really to extreme to resort to package managers which take over your entire system or having to run an entire second system just to be able to run a piece of software.

[gebner]

@rowanG077 Feel free to look at my nixpkgs fork: https://github.com/gebner/nixpkgs/commits/cadquery CQ-editor doesn't work with the upstream pythonocc, so you might need to change the pythonocc-core sources to https://github.com/CadQuery/pythonocc-core/

[adam-urbanczyk]

@rowanG077 @ilya-epifanov assuming you are on Windows could you try the following way of installing miniconda:

start /wait "" Miniconda3-latest-Windows-x86_64.exe /InstallationType=JustMe /RegisterPython=0 /S /D=%UserProfile%\Miniconda3

In general I use the InstallationType=JustMe and RegisterPython=0 options and I have never experienced issues you are describing.

[tolot27]

It runs fine at my Laptop (Win10 x64), too. The advantage of Conda is that you can create different environments (cqgui in the case of CQ-Editor) with different package versions.

I've created and update.cmd which I use to start CQ-Editor while keeping up-to-date with the sources:

@echo off
git fetch upstream
git checkout master
git merge upstream/master
conda env update -f cqgui_env.yml -n cqgui --prune
conda activate cqgui
python run.py
conda deactivate

[rowanG077]

@gebner Thank you! I got cadquery working in a nix environment now by using part of your commits as a reference. Are you planning on upstreaming? If not I will try to get cadquery and CQ-editor into nixpkgs.

@adam-urbanczyk
Isn't it possible to package binary dependencies with pypi? I thought that stuff like python-opencv delivers the opencv binaries with the package itself. Wouldn't this be possible for cadquery as well?

[gebner]

@rowanG077 Not at the moment, feel free to submit a PR to nixpkgs.

[dcowden]

I'm feeling like docker-on-conda is the right answer. Conda works well when you want full control and full integration into your environment, and for greenfield installation. Docker works well when you want no muss and fuss just works install that disrupts nothing. So I think the best option is the existing conda based packages, with an additional docker container that has cq already installed (via conda of course)

…

On Fri, Jun 21, 2019, 6:27 AM Gabriel Ebner ***@***.***> wrote: @rowanG077 <https://github.com/rowanG077> Not at the moment, feel free to submit a PR to nixpkgs. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#153?email_source=notifications&email_token=AAJ44A74ABS3SX5BEGBSUXLP3SUHLA5CNFSM4HY6ZHU2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODYIC4NY#issuecomment-504376887>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAJ44AZSPQ3TAGTNZTYGIMTP3SUHLANCNFSM4HY6ZHUQ> .

[adam-urbanczyk]

@rowanG077 @ilya-epifanov any updates on trying the local install?

@rowanG077 yes it is indeed possible to include binary dependencies in a wheel. It is not really practical though, especially for a project with so complex dependencies. If you don't believe me, take a look inside of the wheel that the project you mentioned is providing.

@dcowden agreed. I'll close this issue and open a specific one for docker image. It would be great if someone from the community could pick it up - I don't have the bandwidth and experience.

[adam-urbanczyk]

@jhol I propose to move the discussion here.

[adam-urbanczyk]

I recently found this project which might allow easy conversion of conda to pip packages https://github.com/regro/conda-press I still don't like this approach because it will result in embedding of all the non-python (OCCT, freeimage, ... ) deps in the package. Do we really want to go this way?

[rowanG077]

I have created nix expressions for cadquery and CQ-editor a couple of months back. I still use them.
This might also be an alternative instead of pip. Big advantage over conda is that it does not pollute the environment and actually works sanely.

https://github.com/rowanG077/cadquery-nix

[marcus7070]

@rowanG077 Nice to see another nix user! I packaged cq-editor in nixpkgs, it's in 20.03 release. https://github.com/NixOS/nixpkgs/blob/20.03-beta/pkgs/applications/graphics/cq-editor/default.nix

Did you manage to get this working in a non-NixOS environment? I had a go at it but ran into problems connecting the nix installed cq-editor to the Ubuntu installed graphics driver. Here is a discussion on the same problem but for a different package: NixOS/nixpkgs#9415

A solution would be to get the user to run cq-editor through this: https://github.com/guibou/nixGL but it's probably still convoluted enough to turn users away from the nix method and back to conda.

[rowanG077]

@marcus7070 A great! I was planning on getting it into nixpkgs but never got around to it!

I haven't tried it just using nix since I run NixOS. But I'd wager mine has the same problem.

[roipoussiere]

I'm working on CQ-editor flatpak, that could be used for just CadQuery. I keep you informed here: CadQuery/CQ-editor#76 (comment)

[vlad0337187]

Used command to install CadQuery, it installed everything into /usr, replaced system python with own and didn't wanted to uninstall it.
Decided to reinstall my system.

So I think this issue is actual.

Pip does not really support binary depandancies like oce.

Can't any binary files just be copied using setup.py

I'm working on CQ-editor flatpak

That would be awesome.
Use Linux Mint, Fedora, both have preinstalled and configured Flatpak.

[GeorgesPaul]

The advantage of Conda is that you can create different environments (cqgui in the case of CQ-Editor) with different package versions.

The disadvantage is that Anaconda never ever seems to work, whereas in my experience venv (managed by anything but conda), system interpreter en even pipenv work flawlessly every time.

Example (this is me literally trying to get this to work on my system as I type this):

Step 1: conda create -n cadquery

Fatal Python error: init_import_size: Failed to import the site module                                                  
Python runtime state: initialized                                                                                       
Traceback (most recent call last):  File "C:\Python39\lib\site.py", line 73, in <module>                                                                      import os                                                                                                             
File "C:\Python39\lib\os.py", line 29, in <module>                                                                        
from _collections_abc import _check_methods                                                                           
File "C:\Python39\lib\_collections_abc.py", line 12, in <module>                                                         
GenericAlias = type(list[int])                                                                                      
TypeError: 'type' object is not subscriptable          

Fixed the above problem. Let's try again:

Cannot set up a python SDK 
at Python 3.8 (dactyl-python) (C:\Users\xxx\.conda\envs\dactyl-python\python.exe).
The SDK seems invalid.

Wut? Why would it even...!?

uninstall and reinstall anaconda3 a few times to try again

uninstall anaconda3

try miniconda instead

manually set conda.exe env path, because that somehow didn't happen during install

conda activate cadquery

CommandNotFoundError: Your shell has not been properly configured to use 'conda activate'. 

k? That's probably not supposed to happen uninstalls miniconda

I realize environments are left behind in some directory, removes 6 GB of environments manually

install miniconda again. Installation mentions that it's recommended to start anaconda from start menu to set environment variables

anaconda/miniconda does not appear in start menu

Google how to set miniconda in env path

Can't find conda.exe anywhere, reinstall minconda3 to let installation add miniconda to path, against installation recommendation yet according to documentation recommendation (they contract each other)

Finally figured out what the problem was: I had Python 39 installed, but Conda can only handle up to Python 38 (which is unfortunate, because I would like to use dataclasses which are a Python 39 thing). Deleted all references to Python from environment variables (including Pythonhome/pythonpath), reinstalled minconda, chocolatey refreshenv, closed and reopened terminal and now the conda command works.

On to the next challenge: set up Conda env in Pycharm and see if cadquery will work.

Three hours later: can start coding. Day is over. Have to go to bed.

Disclaimer, this is my personal opinion and I'm probably a n00b, but: I hate anaconda. Messing around with toolchains is my main frustration with coding. This is not the first time random conda crap makes my cry. I've made it work in the past, I've worked with it in the past, but I just can't get it to work now for the above reasons. It's unfortunate that this is not explained in docs that I found and even more unfortunate that Miniconda install doesn't detect that Python is already on the path and might cause problems (and I can't use system python now? I'm confused?). And this is even before all the potential environment and dependency mess. ugggggggggggg. I'm not trying to flame cadquery devs here, I love cadquery itself, it's awesome. My goal is to just give a report of "a random day of a random dude who wants to use cadquery" and the one and only massive struggle that I run into: anaconda.

[adam-urbanczyk]

YMMV but this works in the CI:

cadquery/appveyor.yml

Line 17 in 4c77c87

- set "PATH=%MINICONDA_DIRNAME%;%MINICONDA_DIRNAME%\\Scripts;%PATH%"

You might be also interested in using the prepacked version of CQ-editor (and CQ), for now available from here:
https://github.com/jmwright/CQ-editor/suites/1584433493/artifacts/28713792

It is not built daily ATM though.

[adam-urbanczyk]

Finally figured out what the problem was: I had Python 39 installed, but Conda can only handle up to Python 38 (which is unfortunate, because I would like to use dataclasses which are a Python 39 thing). Deleted all references to Python from environment variables (including Pythonhome/pythonpath), reinstalled minconda, chocolatey refreshenv, closed and reopened terminal and now the conda command works.

I'm not sure what you mean by "conda cannot handle Python3.9", the following works for me:

conda create -c conda-forge python=3.9 -n py39-demo

Note though that OCP and CQ are not built for Python 3.9 yet.

[GeorgesPaul]

I'm not sure what you mean by "conda cannot handle Python3.9", the following works for me:

conda create -c conda-forge python=3.9 -n py39-demo

Note though that OCP and CQ are not built for Python 3.9 yet.

I'm not sure why the miniconda docs say the following then? I couldn't even get Conda itself to run at all without errors as long as I didn't have Python 3.8 installed on the system (unless conda magically started working due to some other thing a fiddled with).

Or is it that: miniconda needs system Python 38 for itself to run, but can run environments within itself that are Python 39? This was answered below: yes.

[Georges-Paul]

@as08gf9uw0tjawtegi Torrent means unpredictable bandwidth and availability.

I don't understand this argument. How is a traditional webhost with x amount of bandwidth hosting a Python package more predictable and available than that exact same host seeding a torrent of the same package with the exact same amount of bandwidth?

Do you believe that hosting bandwidth is somehow magically "wasted away" into the torrent network when you seed a torrent vs host a file the traditional way?

[fedorkotov]

Do you believe that hosting bandwidth is somehow magically "wasted away" [..]

No magic involved. Just human nature. People tend to seed only what they use/watch/otherwise utilize now. Few seed something for the greater good. Even fewer do it from always-on server. Because of that some obscure and old packages would be hard or impossible to download. This is what I was talking about.

This is not the place to discuss this initiative. CadQuery is not PyPI. If I'm wrong you probably should pitch this idea to pip maintainers at https://discuss.python.org/

[fedorkotov]

For anyone interested in @as08gf9uw0tjawtegi's torrent-based binary hosting for pip idea. I see they have started a topic at https://discuss.python.org/t/torrent-client-in-pypi-for-package-binary-distribution/9417

[dstufft]

FWIW, it doesn't matter to me whether cadquery hosts on PyPI/supports pip install at all or not. I think every project should support the tooling that works best for them and their users. However I just wanted to clarify/point out a few things as a PyPI maintainer/admin!

Easiest/happiest thing first.

• API to get dependencies without full download.

This is coming, we've had a rough idea of what to do for awhile now, and we were just missing someone with the free time to go through and write it up as a proper PEP. That happened and PEP 643 is now accepted and is currently being implemented.

• Distributing large binary payloads as separate downloads.

This is still a problem. In the linked thread under "heated discussion" (which I don't think was actually heated! but that's neither here nor there) Dustin (one of the PyPI maintainers/admins with me) laid out the problem with several possible solutions. We don't have a solution to this, but I'm pretty sure that everyone involved wants to solve this problem. Right now it's stuck in the "discuss possible ideas" phase, largely because nobody has stepped up to write, submit, and champion a PEP for a possible solution (not that that PEP would be guaranteed to be accepted, but that's how those projects make decisions).

The Venn diagram of people who have the "large binary" problem, people who care/want to work on pip/PyPI, and people who have the time to work on the above is pretty small, so it'll likely languish until someone gets more time, it bubbles up to be a much larger problem, or someone external champions an idea that gets successfully accepted.

[jchidley]

I have CQ-editor working on my "macOS Big Sur" "MacBook Air M1" (Apple Silicon ARM based chip). I also use Windows 10 devices. I really can't remember how I installed CQ-editor (possibly the binary download?).

CQ-editor (and Jupyter-CadQuery) are all very nice but I'd like use a proper IDE (in my case Visual Studio) in order to better use and understand Cadquery. This has proved extremely difficult and hence, in my research, I found this thread. Sadly, even after reading everything above, I still don't have a working solution.

To increase adoption of cadquery, a key requirement is easy installation of it. That means that either installation should be a single operation or that there should be concise and clear documentation to follow (actually, there should always be such documentation).

I avoid using conda because I find it buggy, difficult to use and because it causes conflicts on my systems.

Should I ever manage to get this to work, I'll be documenting it.

[WizardUli]

FYI: Last few days I've been intermittently working on my own attempt at creating Nix flakes for pywrap and OCP all that while learning how to do it properly. I know that there were some tries to do it but all links in this issue I've opened so far led to repositories almost 2 years old + attempts in nixpkgs repo seem to also have been abandoned. Please correct me if I'm wrong.

Btw. my goals are following:

• pywrap, ocp and cadquery must be easily buildable locally from source code. No hackary like repackaging conda packages! Also use normal OCCT package (of a properly tested fixed version) from nixkgs as a source of headers not the ones added/hardcoded into the repos as submodule.
• Package libclang's missing python bindings and provide them as an nixpkgs overlay in a flake until it's in nixpkgs.
• Each project should have nix flake inside its repo. One could then directly install them using their github urls. CQ maintainers would have to be OK with it of course.
• For each project also provide a development shell inside its flake so one can just fire up VSCode/ium inside it and work on the code.
• Finally provide an exemplary devShell where CadQuery is installed so one can open open VSCode/ium or whatever editor inside it and start drawing immediately.
• Also package CQ-editor and provide an exemplary devShell with both CadQuery and CQ-editor.

So far it's going good but I'm going to have to add a parameter into pywrap through which one can fully specify all clang's parameters. --include is not sufficient since Nix does not use UNIX-like filesystem hierarchy with global libraries and everything from sysroot to libcxx include paths (-isystem not -I) have to be specified. Not to mention a possibility of crosscompilation. Those flag are calculated automatically by nixpkgs's buiild infrastructure but have to be passed in when not using clang's wrapper shell script.

[jchidley]

Nix is new to me. Can this package manager be used for non NixOS systems (Windows, MacOS)?

I'm with you about the local install without magic.

[WizardUli]

Nix is new to me. Can this package manager be used for non NixOS systems (Windows, MacOS)?

I'm with you about the local install without magic.

It works on MacOS but not on Windows, at least not natively but perhaps it could work in WSL?

[jchidley]

It works on MacOS but not on Windows, at least not natively but perhaps it could work in WSL?

using WSL isn't for the faint hearted.

[Jojain]

@jchidley

To increase adoption of cadquery, a key requirement is easy installation of it. That means that either installation should be a single operation or that there should be concise and clear documentation to follow

What you say is misleading this is definitely provided but it involve conda. Anyway I see several solutions :

1. Install miniconda, this avoid most of the burden of Anaconda while retaining the easy install of binary package anaconda provides ( You can also look at mamba and micromamba that can also be a good replacement)
2. CQ-editor and jupyter-cadquery allow you to use an external editor, CQ-editor can refresh the view when you save a file (that can be outside the editor) jupyter-cadquery as a external viewer that run in your browser and gets updated when you call the show function in your script.
3. You can build OCP and the others cq dependencies from source but that would be a pain

PS : Using WSL is actually not very complicated

[jchidley]

@Jojain I guess we have different ideas of what is easy. Anything that involves conda (or miniconda or WSL) isn't easy for the average user. If you want to grow the user base of this product beyond power users, it has to be trivially easy to install.

Having said that https://github.com/bernhard-42/jupyter-cadquery on Windows works well when using VS Code and the jcv viewer. I only found out about this option today.

As far as MacOS/Apple Silicon the only working solutions appear to be the binary download of CQ-editor and the Docker image for jupyter-cadquery. Or are there some instructions that I have missed?

[Jojain]

@jchidley
CQ-editor is easy to install and gives you something to start with and I think would fit most of the average newcomers, once they want more they can consider using conda/wsl or any otherway that exists to get a cadquery install.

That being said, answering your first question, have you tried activating this and using an external editor :

[jchidley]

@Jojain using CQ-editor in this way means that it'll be working from the same python source file?

In another post @wcraigtrader pointed out that CQ-editor isn't the most robust environment: it's good for smaller projects or code snippets. Given the choice, I'd rather go with the jcv viewer.

[Jojain]

@Jojain using CQ-editor in this way means that it'll be working from the same python source file?

Yes, you open your file in cq-editor and in your editor of choice, you make your change in your editor of choice, and each time you save your file, CQ-editor notice it and rerun your file.

If you have the choice I would also advice using jcv but we were talking on easy workaround here.

[BKLronin]

I had the same problems from within Code OSS. Cadquery installation went well with conda but I had to select the conda python interpreter to make it work from within VScode.

Just to rule this out :P

[Hecatron]

I stumbled across this issue recently after reading a Hackaday article and I remember in the past (although this was a couple of years back) having issues with conda on windows (path related issues). I suspect it probably works better with a unix environment.

One thing I might try experiment with if I get time is the use of https://github.com/conda/constructor
The idea being you'd have 3 ways to install things

• The first being the usual way via conda
• The second being via a installable exe / bundle created with constructor (standalone install) with everything including cadquery included.
• The third being similar to approach two but just bundling the C++ dependencies cadquery needs, then installing cadquery / any python depends via pip. Then you'd just need some way for cadquery to find the installed binary libs / blobs, probably via an environment variable or something

Approach 2 would be the easiest / quickest for a windows install
Approach 3 would be best if you wanted to use a newer / local version of python

In theory it wouldn't be idea as you'd need to manually update the libs whenever cadquery was updated, but it would avoid issues with conda / miniconda installs for those that are non technical.
Also it may be possible to set this up via github workflows so that things are auto generated on new version tags.

[adam-urbanczyk]

@grbd do you think that your option (2) is significantly different than the zip bundle of CQ-editor that is currently available?

Regarding PATH issues on windows, you need to select certain options to get a fully portable install - we are updating the docs.

[Hecatron]

I would say option(2) would be very similar to the zip bundle of CQ-editor, although I did notice there was no python.exe in there unless I'm missing something.

The approach I've taken so far which seems to work fairly well under windows
Is install miniconda, untick any option for adding to the path etc to avoid it overriding an existing python install

Launch the Aconda shelll

# Update conda
conda update -n base -c defaults conda
# change directory to some place to install
cd C:\Apps\
# create a virtual conda environment
conda create -p cadquery
# Activate
conda activate C:\Apps\cadquery
# Install
conda install -c conda-forge -c cadquery cadquery=master

This gets things working in a directory, although I'd probably prefer option 3 personally.
I think also CQ-editor might be a bit behind cadquery at the time of writing in that I don't think it's marked for compatibility with python 3.10 yet

[jmwright]

@grbd

I think also CQ-editor might be a bit behind cadquery at the time of writing in that I don't think it's marked for compatibility with python 3.10 yet

The development packages mentioned in the CQ-editor readme are based on the current master branch, are built weekly automatically, and can be built on-demand when the community wants/needs it. Python 3.10 support was merged into CadQuery 4 days ago and the builds haven't been set up for 3.10 yet.

I would say option(2) would be very similar to the zip bundle of CQ-editor, although I did notice there was no python.exe in there unless I'm missing something.

The Windows packages include a CQ-editor.exe file. The top level of the packages has a Windows command line script instead of the exe for two reasons.

1. Users didn't like searching through the CQ-editor directory to find the executable.
2. In some cases it's helpful to set environment variables before the exe is called.

We also have the capability of building a monolithic exe file, but the startup times for that format can be glacial.

[rosejn]

I'd like to address some of practical points brought up in the rant(s) above, because they don't really make sense to me. It feels more like people arguing over vim & emacs rather than trying to come to a good solution to empower a community. I'm curious about a couple practical matters brought up here.

First, regarding the distribution of pre-compiled binaries. Who cares about making OCCT/OCP being available as a low-level dependency to other projects? That's not what the goal is here. Just package it up and make it part of cadquery, and if people want to use it like a library they can always depend on cadquery. I just checked, and the cadquery source itself is less than 600k, so this isn't a big deal at all. Many other python bindings to C (and C++) projects do exactly this, like tensorflow. As an alternative, the OCCT+OCP component could be packaged as a tarball, .deb, homebrew, etc., and then this would be installed separately before pip installing cadquery. In the same way that we need to download and install CUDA and CUDNN from nvidia before using tensorflow, this is a pattern that works just fine.

Second, the file size issue... is this really an issue? I just built opencascade 7.5 and the compiled libs + include headers are about 100 MB. I'm curious how this could become 1.5 GB with the addition of "thin" python wrappers, and whether all of the modules are even required. Maybe some of the challenge can be simplified by pruning the build output so that the end result is more manageable?

Last, as a final option, the NLTK example given above which requires a download() call (which means the size is irrelevant because it can just download from a github release link) sounds quite practical. What are the drawbacks of this approach for users? Clearly by the many people who care about this issue Conda is a constant source of pain, and in some cases just isn't an option. That download call can just look in .local/lib/CadQuery to see if it's installed already, and if not download it. This is simple, easy to verify, and not error prone. CadQuery is primarily a user tool, not something that will be deployed, but even if it is that could be setup in a dockerfile and done once on build, which is how most deployments happen these days anyways.

My prediction is that once cadquery is easily installable via pip so people can read a blog post and try it out in a moment of curiosity the user base, interest, projects and tools built using cadquery will all increase.

[adam-urbanczyk]

To begin with, I care about making OCP available as a package and about having sane binary dependency management for CQ. Everything you write is possible, but to me sounds like a hacky workaround (especially the NLTK example you give). Conda offers the best effort to result ratio for delivering something working and a huge number of relevant native packages that are (or could be) used by CQ. For some reasons some people hate it, but so far no one opened a PR with a clean pipeline building a wheel. If you don't want to spend time installing a portable conda distro, why would I spend time on building a hacky pip package? Given limited resources, it is more interesting and productive to develop new features.

With all that being said, there is an ongoing effort to build a wheel, but currently it has no ETA.

[WizardUli]

I haven't tried miniforge yet but with conda and miniconda I had following serious issues:

• The default installation modified my whole user environment.. edited .bashrc or .profile (perhaps both) and done that without asking as far as I remember. (This can be turned off in case of miniconda at least but my opinion is that it's malicious design.)
• Much more important issue is global mutable state:
  Python's venv downloads everything into a folder inside your project (people usually use .venv/ name) and does NOT modify anything outside of it and it is completely movable.
  (Mini)Conda on the other hand assumes with insolence that you have an accessible home folder then downloads everything there and references/uses it from your project. It is detached from your project, cannot be moved with your project and leaves garbage for you to clean up from your home when you are done with the project.
  This is unmaintainable, uncomposable, and hardly scriptable. Maybe it is OK for pure simple direct user but otherwise it is a huge DevOps antipattern aka unnecessary global mutable state.

That are my 2 reasons for not liking *Conda.

[fedorkotov]

Python's venv downloads everything into a folder [..] and it is completely movable

No, it is not movable. At least not easily and reliably. See for example https://stackoverflow.com/questions/32407365/can-i-move-a-virtualenv

In conda you can create as many environments as you like. Same as with venv. And you can remove them as soon as you are done with the project. Same as with venv. It is not worse than python + venv and not harder to manage. It is just different and takes some getting used to.

[adam-urbanczyk]

Conversion became too much off-topic - locking. If anyone manages to develop a working pipeline to build CQ wheels, please open a PR!

[jmwright]

We're just waiting on PyPi to approve our size increase before we can make the cadquery-ocp wheel available, which will allow us to bring back pip install cadquery. Big thanks goes to @fpq473 and @roipoussiere for their work on the wheel builds.

[jmwright]

@rowanG077 We have instructions in the README now for installing CadQuery via pip.

https://github.com/CadQuery/cadquery#cadquery-installation-via-pip

This addresses the OP's original request and so I am closing this issue. If there are other salient points in this issue, they can be broken out into new issues. To be clear, we are NOT dropping conda support for PyPI. Both will exist in parallel because conda has become an important part of our CI pipeline, and because some users will want/need to use conda and some will want/need to use PyPI.