metalpoetza

pyKAN - Pure python CKAN client

Recommended Posts

In case it's of interest to anyone, here's a quick & dirty bash-completion function for pyKAN. Trivial, but it makes my life easier anyway.

#!/bin/bash

_pyKANComOpt()
{
    local cur prev words cword
    _init_completion || return

    opts="-h --kspdir --debug --key --value \
	  --repo --allsettings --allmods --search \
	  --allversions --installed --upgradeable \
	  --module --version --reccomends --suggests"

    cmds="install addkspdir listkspdirs show_settings \
	 show delkspdir list_repos default_ksp \ 
	 add_repo del_repo update upgrade \
	 uninstall change_setting list_modules"

    case $prev in
      --module)
	COMPREPLY=( $(compgen -W "$(./pyKAN list_modules | cut -d' ' -f1)" $cur) )
	return 0
	;;
      --kspdir)
	_filedir
	return 0
	;;
      --suggests|--reccomends)
	COMPREPLY=( $(compgen -W "ask yes no" -- $cur) )
	return 0
	;;                
    esac
    
    case $cur in
      -*)
	COMPREPLY=( $(compgen -W "${opts}" -- $cur) )
 	return 0
	;;
      *)
	COMPREPLY=( $(compgen -W "${cmds} ${opts}" $cur) ) 
	return 0
	;;
    esac
    return 0
} &&
complete -F _pyKANComOpt -o filenames pyKAN

Needs bash-completion, and bash, obviously.

On the whole packaging for the masses thing... I kinda like it the way it is TBH, and I much prefer loose python scripts to a .NET binary blob.
The error messages re. missing deps are pretty obvious, took me all of 5 seconds to install them. Really not sure what the big deal is here?

Again, much thanks for a CKAN client that doesn't constantly get in my way...

Share this post


Link to post
Share on other sites

Ooh that's cool. If you create pull requests with this in an 'extras' directory I'll merge it, I'm sure there will be more similar things that can join it there soon.

Share this post


Link to post
Share on other sites
Just now, metalpoetza said:

If you create pull requests with this in an 'extras' directory I'll merge it

That means I have to sign up for (and figure out how to use) that newfangled github thing, right? Consider this a solid "when I get around to doing that, and the other things". :P

Share this post


Link to post
Share on other sites
3 hours ago, steve_v said:

That means I have to sign up for (and figure out how to use) that newfangled github thing, right? Consider this a solid "when I get around to doing that, and the other things". :P

Heh fair enough. I may just add it myself tomorrow if you don't mind.

Share this post


Link to post
Share on other sites

I'm not sure if I did something wrong with my upgrade here, but I'm getting an error now.  I was able to successfully add my new 1.2.1 game folder, and do a pyKAN update and upgrade, but list_modules is consistently failing:

$ ./pyKAN list_modules
Using KSP Directory:  /home/confusador/Games/KSP121
Traceback (most recent call last):
  File "./pyKAN", line 359, in <module>
    actions[options.action]['method']()
  File "./pyKAN", line 165, in list_modules
    if modid not in result or Version(result[modid]['version']) < Version(version):
  File "/home/confusador/Downloads/pyKAN-0.1.0/libPyKAN/version.py", line 102, in __lt__
    return self.__cmp__(other) < 0
  File "/home/confusador/Downloads/pyKAN-0.1.0/libPyKAN/version.py", line 86, in __cmp__
    if self.numpart(i) <= self.numpart(j):
  File "/home/confusador/Downloads/pyKAN-0.1.0/libPyKAN/version.py", line 52, in numpart
    return int(''.join(re.findall('\d',s)))
ValueError: invalid literal for int() with base 10: ''

EDIT: It occurred to me that I could probably get what I needed by grepping the repocache, and once I found the module name `./pyKAN install --module ContractConfigurator-Tourism` worked just fine as well.  Not sure what it is about list_modules, maybe choking on a new name?

Edited by Confusador

Share this post


Link to post
Share on other sites

I went through and did `./pyKAN list_modules --search <identifier>` on everything in the repocache, and only get the exception on the following 8:

Firespitter
FirespitterCore
FirespitterResourcesConfig
ModuleManager
RetractableLiftingSurface
SpaceDock
SXT
SXTContinued

I don't see anything unusual about those, so I'm not sure where to go from there.  Also noticed that search returned nothing for most identifiers, but I don't know if that's intended behavior since this isn't exactly a normal use case.

Share this post


Link to post
Share on other sites

Seems like something is breaking the version checks in the 1.2.1 repo - I will have a look and try to reproduce it when I can.

Share this post


Link to post
Share on other sites

Here's how to fix the problem - I'm not sure what causes the bug but this makes it work.


 

./pyKAN change_setting --key=minKSPversion --value=1.2.1
./pyKAN change_setting --key=maxKSPversion --value=1.2.1
./pyKAN update

Afterwards it works normally. It seems it has trouble parsing the version number in 1.2.1 for some reason. I will investigate further but in the meantime manually setting the version flags in the settings file works.

Share this post


Link to post
Share on other sites

Oh hai! I just found out that this existed! Very cool! Are you writing your mod installation data to the CKAN registry.json file so users can use both clients? 

Share this post


Link to post
Share on other sites
5 hours ago, politas said:

Oh hai! I just found out that this existed! Very cool! Are you writing your mod installation data to the CKAN registry.json file so users can use both clients? 

Hi, 

No pyKAN uses it's own installation registry - but it does *read* the CKAN registry and knows what CKAN has installed, just not the other way around. I am hoping to start serious work on the next version next week - I'll look into the possibility of doing this as a feature.

Share this post


Link to post
Share on other sites

Cool. Can I suggest you add a "Full implementation of CKAN Spec v1.18" to your To-Do list? At some stage we're going to add a new "replaced_by" relationship to the spec, but I've been too busy to work on that recently.

Share this post


Link to post
Share on other sites

Heh, I had no idea the CKAN guys even noticed or cared about my little project. As it happened I wasn't able to work on it last week - we are in the process of moving house and it ended up taking all my time, so the next version is yet again delayed a bit by real life, but thanks for that information - having the full spec to refer to could be very helpful. Are there any particular deficiencies I should prioritise ?

Share this post


Link to post
Share on other sites
14 hours ago, metalpoetza said:

Heh, I had no idea the CKAN guys even noticed or cared about my little project. As it happened I wasn't able to work on it last week - we are in the process of moving house and it ended up taking all my time, so the next version is yet again delayed a bit by real life, but thanks for that information - having the full spec to refer to could be very helpful. Are there any particular deficiencies I should prioritise ?

I haven't run your program or looked at your code, and I'm not familiar with Python, so I really couldn't say. Supporting "depends" and "conflicts" relationships and metamods are obviously critical, so I assume you have that, and the various "install" modifiers would also be important to prevent mod authors getting reallllly annoyed.

The CKAN project was always set up to separate the Spec, Metadata and Client, so that people can implement their own versions of the Metadata and Client. The Spec is really the only thing that can't be forked/reimplemented without breaking compatibility.

I do think that you'll get more people willing to try out your client if you write back to the CKAN/registry.json. Users would know they can try out your client without being locked in, or needing to delete/reinstall mods if they want to switch back.

Share this post


Link to post
Share on other sites
27 minutes ago, politas said:

I haven't run your program or looked at your code, and I'm not familiar with Python, so I really couldn't say. Supporting "depends" and "conflicts" relationships and metamods are obviously critical, so I assume you have that, and the various "install" modifiers would also be important to prevent mod authors getting reallllly annoyed.

Those are all implemented - I've not had a mod fail to install correctly through it in a long time - I use PyKAN as my own client for day to day stuff -and my current playthrough is on SSRSS, with a whole slew of other mods, and working well.

27 minutes ago, politas said:

The CKAN project was always set up to separate the Spec, Metadata and Client, so that people can implement their own versions of the Metadata and Client. The Spec is really the only thing that can't be forked/reimplemented without breaking compatibility.

I do think that you'll get more people willing to try out your client if you write back to the CKAN/registry.json. Users would know they can try out your client without being locked in, or needing to delete/reinstall mods if they want to switch back.

The main reason I didn't do it that way at the start was to avoid the risk that bugs in my then, still new, project could corrupt people's CKAN systems. Right now the CKAN registry is treated as a read-only access - so pyKAN knows what CKAN has installed, but not vice versa. But the code has been quite stable at the library level for some time now - so it's probably safe to add that feature now. The main place I want to evolve the code hence-forth is on the frontend side, it really could use a GUI.

Share this post


Link to post
Share on other sites

Version 0.1.2 is now available.

A new version of PyKAN with multiple bug features and some new features including a revamped commandline interface with support for multiple modules in a single command.
My thanks to Feanor for his wonderful contributions to this release.

https://github.com/ajventer/pyKAN/releases/tag/0.1.2

Share this post


Link to post
Share on other sites
Posted (edited)

Hi, maybe a bit off topic, but as you mentioned on the readme that you have plans for a future update with a QT user interface, I just like to mention that I have built my application KSP Mod Analyser in Python 3 + PyQt 5. It just analyzes all available mods on SpaceDock, Curse and CKAN and aggregates the meta data for a clean presentation (no mod manager features), but maybe some ideas can be reused. 

You can find my project on GitHub, and here is the forum thread.

I used "PyInstaller" for packaging the stand-alone version which works without having Python installed.

Edited by Ake74

Share this post


Link to post
Share on other sites
20 minutes ago, Ake74 said:

Hi, maybe a bit off topic, but as you mentioned on the readme that you have plans for a future update with a QT user interface, I just like to mention that I have built my application KSP Mod Analyser in Python 3 + PyQt 5. It just analyzes all available mods on SpaceDock, Curse and CKAN and aggregates the meta data for a clean presentation (no mod manager features), but maybe some ideas can be reused. 

You can find my project on GitHub, and here is the forum thread.

I used "PyInstaller" for packaging the stand-alone version which works without having Python installed.

Possibly, but I suspect not -since I wouldn't be writing any new functionality into the GUI at all - the GUI would just do the exact same thing the CLI does, call out to the underlying libPyKAN to do the work, while presenting it all in a nice a frontend. There is a stub pykanqt file in the repo, but I haven't had time to actually work on the GUI due to work-load getting insane this year, was planning to do so on my last holiday but ended up spending it all househunting. Hopefully sometime soon.

Share this post


Link to post
Share on other sites
Posted (edited)

@metalpoetza   There appears to be a issue with pyKAN in relation to KSPIE where an accidentally uploaded version is causing pyKAN  to become unable to update to the latest version. I think some dev need to look into this

Edited by FreeThinker

Share this post


Link to post
Share on other sites
25 minutes ago, FreeThinker said:

@metalpoetza   There appears to be a issue with pyKAN in relation to KSPIE where an accidentally uploaded version is causing pyKAN  to become unable to update to the latest version. I think some dev need to look into this

I have found the bug in pyKAN, and just pushed a fix. The latest commit in git contains it. I will release a new official version with the fix once @minecraft2048 finishes his current work so it can all go into one release. In the meantime you can get the (small) fix by using the master-branch git code directly.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now