Why not upload this package to PYPI?

Freed-Wu commented 2 years ago

Thanks!

dbarnett commented 2 years ago

Eh, it's a kinda specialized tool and not made to be depended on by other python projects. It's not hard to upload but benefit seems small.

Was there some advantage you're looking for in particular? Just removing a step or two from install?

Freed-Wu commented 2 years ago

PYPI has many mirrors which make the package can be downloaded easily when the network is not good (for github). And removing a step or two from install is another reason.

Freed-Wu commented 2 years ago

And I guess https://docs.github.com/en/actions/automating-builds-and-tests/building-and-testing-python#publishing-to-package-registries is helpful for upload to PYPI automatically after every time release.

Freed-Wu commented 2 years ago

Any progress about this issue? Although it is a kinda specialized tool, I still think it has the value to upload to PYPI, at least to prevent name squatting from some malwares.

dbarnett commented 1 year ago

We've had some discussion (+ @malcolmr ). Still kinda low on the list of priorities, but it might be worth doing for this and vroom.

A few thoughts:

I don't have any intention of supporting python 2 and I want to make sure it fails hard and obviously if anyone tries to install it using py2. I think I can tag it as py3-only in pypi but I'd like to make sure it won't end up bypassing our current hacks to block it from running in py2, so users wouldn't start reporting py2 compatibility errors as vimdoc bugs.
I'd prefer if there was one obvious way to install the tools. We don't really have the time and energy to maintain a whole suite of installation options. If we're trying to make it easy to install via pypi, we might want to stop publishing debs (see #125)?
I also don't want to have people using vimdoc internals as a python library and set any expectations we won't be moving the code around. We might want to mark a bunch of the code as private besides the main entry point to run vimdoc on a given file. I'm also not sure we won't someday end up rewriting in some other programming language, and it would be nice if we didn't have a bunch of python-specific installation instructions to rewrite if we ever did.

Freed-Wu commented 1 year ago

don't have any intention of supporting python 2 and I want to make sure it fails hard

:+1:

make it easy to install via pypi, we might want to stop publishing debs

Create deb, rpm, or other package from wheel should be packagers' work :+1:

I'm also not sure we won't someday end up rewriting in some other programming language

If it will be rewrite in other language (and keep same function), I think this issue and all issue about python can be closed now.

dbarnett commented 1 year ago

If it will be rewrite in other language…

I mean, I don't think we have any immediate plans to do that, but wherever we can make it so users of the tool don't have to care what language it's implemented in, we should.

google / vimdoc

Why not upload this package to PYPI? #118