vapoursynth / vsrepo

A simple package repository for VapourSynth
MIT License
106 stars 27 forks source link

vsutil already releaed v0.4.0 for servel days. #127

Closed fuchanghao closed 4 years ago

fuchanghao commented 4 years ago

https://github.com/Irrational-Encoding-Wizardry/vsutil/releases/tag/0.4.0

Is that possable to update it form 0.3.0?

theChaosCoder commented 4 years ago

Yeah, I avoided to update this package since it is a "python package" now. I think it is still possible to just add (and rename?) this file: https://github.com/Irrational-Encoding-Wizardry/vsutil/blob/master/vsutil/__init__.py Or better remove it from vsrepo completely?

There are some other packages that uses a python setup like this one https://github.com/Irrational-Encoding-Wizardry/lvsfunc/tree/master/lvsfunc The author here has split his script in many sub files. In this case I don't know if vsrepo could even support it...

General question: How can I update these python packages in python ( in case I installed it via python setup.py)? Only via pip? I installed pip-review for that and it "detected" vsutil and installed the new version of vsutil automatically.

But this leaves me with 2 files

So the question is: how should we handle "python packages" in vsrepo?

stuxcrystal commented 4 years ago

I think it is still possible to just add (and rename?) this file

I do not. That vsutil will be split up further is effectively decided. (https://github.com/Irrational-Encoding-Wizardry/vsutil/pull/45 and https://github.com/Irrational-Encoding-Wizardry/vsutil/issues/38)

For actual solutions:

  1. There is already precedent for packages with multiple files (although they are plugins): https://github.com/vapoursynth/vsrepo/blob/master/local/w2xnvk.json (I just picked files at random until one turned up)
  2. vsrepo already supports writing package metadata allowing it to be uninstalled by pip: https://github.com/vapoursynth/vsrepo/blob/423d1c5060f078bbe2cde01b58d648e4d539c55b/vsrepo.py#L443
  3. Allow vsrepo to do the same for python scripts. That should cover 90% of cases. Those that actually do compile something, see point two:
  4. Allow vsrepo to unpack whl-files (which are just zip-files) for python packages that do in fact contain compiled code. A setup.py file can create whl-files by executing python setup.py bdist_wheel (requires pip install wheel <1>). In this case I'd say, if the package author does include compiled (excluding plugins of course) code with his python module and he is not providing a whl-file, he is SOL <2> and should provide a whl to be included in vsrepo. Installation of whl-files is actually easy, just extract the relevant files <3>. (This will cover 95% of the remaining cases).
  5. Everything else: Just pip-install it. Those packages do in fact far more than just install a module. (For example they are most likely some sort of application)

Personal note: Prefer whl-files as they do not need any setup.py or any other python-script to install (in 99.9% of cases)


Note <1>: In fact, current versions of pip will issue a warning if it is executing a setup.py file without having wheel installed. Note <2>: In fact, vsutil does have a whl-distribution located here: https://files.pythonhosted.org/packages/a7/bc/3022df836837f134ba1a376b0c497a2b58b412d4f8bfbe9e57cfbdad39b7/vsutil-0.4.0-py3-none-any.whl Note <3>: An overview of the .whl-extraction process is described here https://www.python.org/dev/peps/pep-0491/#id6

myrsloik commented 4 years ago

Sure is a mess! I'm tempted to recommend that scripts are hosted on pypi and that we simply wrap pip in vsrepo for those. The advantage would be that the scripts also can have plugin dependencies listed in its vsrepo package. Or something like that. This idea is probably horrible but it doesn't matter since I'm busy with VS anyway...

myrsloik commented 4 years ago

I've started to implement wheel support in the pywheel branch. All unimplemented features (putting files in anything but site-packages) will throw an error on install. Installation and version detection is working. Additional planned stuff: Somewhat proper uninstall as well Scanning the pypi json for package updates

theChaosCoder commented 4 years ago

Hmm but this wouldn't work with the new wheel type install thingy? https://github.com/Irrational-Encoding-Wizardry/lvsfunc Because I don't see it on pypi.org

stuxcrystal commented 4 years ago

If it has a setup.py chances are very high that it in fact does. You just need to ask the maintainer to provide them for windows.

myrsloik commented 4 years ago

@theChaosCoder The wheels don't necessarily have to be on pypi either and they're easy to create for a bundle of scripts. Plus I suspect that once it's made the recommended way people will get with the program if they have multi-file creations.

myrsloik commented 4 years ago

Fully functional pypi scanning implemented now as well. The remaining things to fix in are now: (pull requests/commits welcome)

  1. Removes all files in RECORD but not dirs if empty, not a big deal but pull requests welcome
  2. Use zipfile instead of external exe to compress vspackages3.zip

And updating all those poor python packages

theChaosCoder commented 4 years ago
.\vsrepo.py install vsutil
Failed to open vspackages3.json. Run update command.

A vspackages3.json file is in the same dir, compiled manually ...

EDIT happens with every command

myrsloik commented 4 years ago

Did you forget to use portable mode? Works here

theChaosCoder commented 4 years ago

Argh yes

theChaosCoder commented 4 years ago

Two things I noticed so far:

  1. In portable mode a "installed" vsutil version is not recognized as installed (List is empty)
  2. In non-portable mode vsutil is reported as version 0.2 ( I double checked and removed all old scripts in appdata and python site-packages)

.\vsrepo.py install vsutil

Successfully installed VSUtil 0.5.0
Updating VapourSynth stubs
1 package installed

.\vsrepo.py installed

Name                      Namespace       Installed   Latest      Identifier
*VSUtil                   vsutil          0.2.0       0.5.0       vsutil
myrsloik commented 4 years ago

You didn't remove the dist-info dirs. Have to do that as well. I'll give portable mode a try and see why it fails.

theChaosCoder commented 4 years ago

You mean vsutil*-dist-info? I removed it as well (+ checked with WizTree for vsutil files/folders)

myrsloik commented 4 years ago

I'm fairly certain I fixed the phantom version number bug and the portable one too. Give it another try.

theChaosCoder commented 4 years ago

Looks good now

theChaosCoder commented 4 years ago

For create-package: Can we safely assume that wheel urls always be like http(s)://something.whl ?

If yes then I'm done.

myrsloik commented 4 years ago

Actually I'd implement it to simply take a pypi package name (like vsutil) and then grab everything from there. I don't think there will be very few people making wheels but not stuffing them on there. Or did you mean something else?

theChaosCoder commented 4 years ago

It's just for detecting the type by url so you don't need an additional parameter.

.\vsrupdate.py create-package -pname "vsutil" -url "https://files.pythonhosted.org/packages/73/c8/6dd6f80356131fe2f8b0da4499dcc2ee26d2207e95389d409c5c61b5bd32/vsutil-0.5.0-py3-none-any.whl"

There is a --script parameter because plugin and script = zip files.

if it's hosted on https://files.pythonhosted.org (aka pypi.org) then an autoupdate is triggert otherwise just save the json. I assume not everything will be automatically on pypi...

myrsloik commented 4 years ago

Sounds reasonable I guess. Commit it.

theChaosCoder commented 4 years ago

I pushed it to pywheel.

myrsloik commented 4 years ago

I guess this is done then. Now all we need are some more wheels