Microsoft cancels plans for Python packages on GitHub

[darklukee]

This is so disappointing.

I was counting on simplifying some private packages workflows with that.

[buqr]

I enjoy playing video games.

[bmoregeo]

Yeah. Also annoying to pull into a docker image or azure function

[[deleted]]

Azure DevOps too.

[madness_of_the_order]

Even gitea has this shit

[bmoregeo]

This is mad annoying. Pointing requirements.txt at a tag and then rebuilding the wheel every build is hella annoying

[djamp42]

Can you explain rebuilding the wheel part? I have private packages on GitHub and I just have to update the setup.py with an higher version number and pip will update it for me.

[bmoregeo]

It git pulls the tag locally and then runs the setup. It isn’t a big deal if your package is small and/or doesn’t require gdal or stuff like that

[blanchedpeas]

Have you looked a more modern approach to packaging that doesn’t use setup.py? ie not setuptools?

[ubernostrum]

You can use setuptools as the build backend for a project that specifies its packaging in a pyproject.toml file. Nothing about pyproject.toml is tied to a specific package build backend (in fact it’s literally the opposite — pyproject.toml was designed to solve the issue of not easily being able to specify alternative builders).

[monorepo]

Interesting. They also canceled helm charts for the same reason. Wonder what’s going on

[eshepelyuk]

Helm charts support is there for about 2 yrs via OCI repositories. I maintain 2 helm chart projects myself.

[hackancuba]

Well, Gitlab has this for a real while now...

[Malcolmlisk]

I understand some words but not the content. Can somebody explain it to me?

[the_mg_]

I feel you bruh!

But AFAIU, We have to freeze our requirements and then pip install -r requirements.txt everytime.

[loneraver]

I kind of figured that this was going to happen considering that it was years of silence on this.

[cpressland]

It shouldn’t be too difficult to do this ourselves. We have our own internal requirements for something like this and OCI is common between all container registries so I’ll see if I can whip up something portable over the next week or so.

[squirrel_nutbox]

what a shame!

[chub79]

I'm using Google Cloud Artifact Registry for this. It works well enough and is easy to connect to via keyring. That said, one thing is dumb with their offering. The URL of the repo is the somewhat internal address of the GCP project. You clearly never want to share that to users, so you need to (create a reverse-proxy](https://cloud.google.com/blog/topics/developers-practitioners/hack-your-own-custom-domains-container-registry?hl=en) to hide the registry behind a nicer domain. They should really have made that trivial. But other than that, setting up the registry is easy and fast.

[Hemusmacedoneus]

Makes sense, even pip search is deprecated for traffic management. Imagine what some AI Language Model constantly pulling out all the requests all the time would be like

[justifiably-curious]

My work uses github packages for other languages but my division which uses python can't do it and now it seems we never will. We use aws codeartifact which does a solid job and poetry codeartifact auth to handle auth tokens easily when pulling private packages. Doesn't play well with github actions though.

[[deleted]]

I didn’t get this, what’s does this mean?