Hacker News Reader

Comment by mikepurvis | Hacker News Reader

Looks like Docker, node/npm, ruby/gems, java/maven, and nuget... but no Python? Seems an odd choice for the one to leave out.

View on HN

Github has traditionally been a Ruby shop and once you are a Ruby shop, you can use Ruby to do anything that you could use Python for so there is no need to touch Python other than may be data science. That means they would have built a lot of expertise in Ruby and comparatively very little with Python. So it's understandable that they are able to add support for Ruby before python. It must have been easier to do for them and also been much easier to "dog-food".

That said, I'm sure Python, Go, Rust and other languages will be supported very soon.

I'm puzzled by the fact that you've been downvoted, as far as I can tell everything you've said is valid, and certainly not anti-python.

Doesn't Go already download packages from GitHub?

Yes, Go uses git repo paths to download source code.

Yes but in future Go will most likely use a package server that will act like a proxy, a cache and way to verify packages. There will be many implementations. Some engineers at Microsoft are building one called Athens. Go team will release one as well. Github could release yet another one.

Maybe because PyPI has a closer relationship with Python than the other package managers have with their core tech?

I don't see how that's relevant. Hosting your own Python package index isn't easier than hosting any other, as far as I'm aware.

Less technical and more political. Python has a bureaucracy that can take let’s say “a while” to decide things. If GitHub approached them about this it wouldn’t surprise me if they’re still debating whether to condone it.

See for example this PEP suggesting they use GitHub issues for the CPython repo hosted on GitHub, opened a year ago https://www.python.org/dev/peps/pep-0581/

There's nothing required from PSF to create own repo. I created one myself on S3, all you need is then just update pip.conf to use it. Pip also has functionality to support primary repo and a backup, so they don't need to make their repo a pass through to PyPI, pip basically can be configured to look up first the custom repo and if package is not found then fallback to PyPI.

There's no technical or political obstacle here.

Hosting a Python package index is much simpler, just dump the files in a web accessible directory with a directory listing and specify it with `--find-links`.

https://pip.pypa.io/en/stable/reference/pip_wheel/#find-link...

You can also link directly to a package with `--find-links` if you specify an egg fragment, e.g. 'https://github.com/project/reponame/tarball/version#egg=pack.... (The version must match that in setup.py.)

PyPI has no closer relationship to Python than the other options to their respective language. Similarly to others PyPI also runs out of an http server. There really is nothing tied to Python.

No php composer either.

Keep in mind it's in beta.

GitHub, at least from what I've seen publicly in the past, uses all the ones they support except maybe Java/Maven; I've never seen anything about them internally using Python.

So, it's not really all that surprising of an initial set of choices for them to make.

Notice how you were able to call out the de facto package manager for those languages, but didn't for Python? I would imagine supporting the various Python package managers in use would be a bit annoying.

pip is the default package manager for Python, and while anaconda knows how to install from PyPI, you just pip install things into anaconda environments. So, the answer is "pip".

If anything, Pip is so tightly integrated into Python that people probably forget they are separate projects.

Third party proprietary tools like bintray/artifactory manage to do it without too much trouble. Honestly, there aren't really that many formats to support for Python these days— if you don't mind kicking some legacy to the curb, sdist, bdist, and whl pretty much covers it— any other splintering of the ecosystem is on the tooling side, but all the tools that matter still generate one or more of those three formats as the archive.

Actually bdist is legacy is not even used anymore you basically use whl (bdist_wheel), generate packages for specific platform and also provide sdist (source) so people that use platform you forgot about still can use your package. If you're lazy you can just upload sdist.

There's only one - PyPI used by pip, and you can run it on a basic web server.

There only other that I heard is anaconda, but that's made by 3rd party (not affiliated fir PSF), it is not just Python but also R since it targets scientific community. I also believe it is primarily used by windows users. It is packaging for scientific tools that happen to also have python.

Edit: from another comment I see that underneath anaconda apparently uses PyPI for python packages (I didn't know, since I never used it) so it is not even a proper repo, just an abstraction to PyPI (and possibly whatever R is using)

Bit like security alerts which were initially just JS and Ruby. Indeed odd.

I don't find it odd at all. It's likely just "languages we use" and "languages that would see enterprise value". Certainly Ruby/Javascript fall into the former, and Java/C# fall into the latter.

Not saying Python doesn't have enterprise value, but we have to consider that this is an MVP, so it makes sense for them to limit to a subset of languages they feel comfortable about.

people may be reading too much into this. notice there is no go either? maybe because we often tend to pip install and go get directly from github repos and releases? so whether they are working on proper integration or not, nothing is being missed here.

What would it be? Go doesn't have any packaging system.

Installing directly from github is possible, but it works ok for a one off, if you have a package with your own dependencies then that doesn't scale.

It also covers source installations it doesn't work well for compiled.

Reply on news.ycombinator.com