vimdoc icon indicating copy to clipboard operation
vimdoc copied to clipboard

Why not upload this package to PYPI?

Open Freed-Wu opened this issue 3 years ago • 4 comments

Thanks!

Freed-Wu avatar Sep 10 '22 10:09 Freed-Wu

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?

dbarnett avatar Sep 13 '22 01:09 dbarnett

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 avatar Sep 13 '22 05:09 Freed-Wu

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 avatar Sep 13 '22 06:09 Freed-Wu

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.

Freed-Wu avatar Oct 10 '22 17:10 Freed-Wu

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.

dbarnett avatar Nov 26 '22 20:11 dbarnett

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.

Freed-Wu avatar Nov 27 '22 03:11 Freed-Wu

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.

dbarnett avatar Nov 27 '22 18:11 dbarnett