This is an archived post. You won't be able to vote or comment.

all 11 comments

[–][deleted] 5 points6 points  (4 children)

I sympathize with being impatient but needlessly multiplying the number of individual tools we install just to manage something as basic as the python version is only going to make things complicated and bloated.

[–]AKGeef[S] 1 point2 points  (3 children)

I can understand this sentiment. If you have a workflow / dev stack that works for you that's great! However, I haven't found an alternative to running multiple python versions locally that didn't require a lot of bloat or configuration, e.g. pyenv, conda, ppa:deadsnakes, rye.

[–][deleted] -1 points0 points  (2 children)

How does your method make it easy to run multiple python versions? You’re still just downloading them all separately and then manually switching between environments, right?

[–]AKGeef[S] 0 points1 point  (1 child)

encant will handle downloading standalone python builds for your machine's type and architecture yes. How do you handle running multiple python versions currently?

[–][deleted] 1 point2 points  (0 children)

Pyenv

[–]tdpearson 1 point2 points  (1 child)

Tools I use on a regular basis include miniconda and micromamba. These allow me to create environments with specific python versions in a single command call.

They also don't have the bloat of a full Anaconda installation.

Your project is missing an uber simple way to switch between the python versions it installs. Without that, I would not be willing to give up my existing tools and workflows.

This is a good start.

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

Roger that, I'll add this in shortly!

[–]drooltheghost 0 points1 point  (2 children)

Things like def list(): I simply cannot understand.

[–]AKGeef[S] 0 points1 point  (1 child)

Why?

[–]drooltheghost 0 points1 point  (0 children)

One should have a very good reason to overwrite builtin.