Please check out my fork of pyLNP, after you made a backup!
I added a version check and a download feature.
Right now, it is still quite rough, i.e. works on python3 only, it updates everytime you start pyLNP (which might be a bit too much, but I can still change it later) and only uses commandline input/output. Please test it a bit (you can change the version number in the created packages.json in your LNP folder to test the download/extract) and let me know about feedback.
I've only looked the code for now, but I still have comments:
Like Peridexis said, be careful about 100% automatic updates from "original" sources, because you might lose compatibility with the currently installed DF version. If you want to do component-wise updating, there needs to be a step where the user selects which parts to actually update - and you would probably want to leave old versions in case the new one doesn't work right.
You need to keep everything as generic as possible - that includes version checking! Take a look at the code that's already there for an idea about how to deal with that. (You'll need a regex per version checking URL.)
on my todo are:
- only update every x-hrs/days/whatever (specified by pyLNP.user ?)
- make it a more fault tolerant, i.e. no inet connection, extraction failed, no write access,...
- try to get the extract feature done for OSX... Need someone to test it afterwards
- implement LZMA support for python 3.3+
- Get it into the user interface
- Contact dffd admin and ask if it is ok that I have "fun" with their server and circumvent their limitations (python is not allowed)
- add python 2 support
Other suggestions?
I would talk to the DFFD admin sooner, not later. If he says no, then you won't be able to use the code as-is anyway.
I tend to think that handling most cases is good enough, so my logic would be:
- if someone wants to use DFHack on Linux, use xdg if that'll work.
- otherwise make them configure it in the config, and don't spend time trying to make the launcher smart enough to help much.
- if they can't do that, no dfhack through the launcher.
I think this would cover most people under the first point, and those not covered are probably able to finish setting that up themselves. And the worst cast is they have to start DF manually to play with DFHack - hardly a disaster.
To the best of my knowledge, Mint is the most popular distribution these days, and one of its core desktop environments is MATE - where xdg-terminal does not work out of the box, so already there, I would argue you're not covering "most people".
EDIT: exec* is not an option because utilities need to be launched after DF - so it's necessary to find a way to launch DF as an entirely stand-alone process, with its own terminal window. For Windows, I can use the start command; on OS X, I can use open. I haven't been able to figure out a useful possibility on Linux; I don't see a way to make Python do it directly, and I haven't been able to detect which terminal program the user is using to launch a new one. If anyone knows something I don't, I'm all ears.
Is there a reason for this? I think some utilities (DT?) check for DF on startup, but I don't know of any that exit immediately if DF isn't running (and either way, there's no guarantee which will finish launching first). Admittedly, exec() won't work with DFHack if PyLNP is launched without a terminal window, so it's not a complete solution.
I could probably get away with doing it the other way around, but as you mentioned, that only helps for the case where there is a terminal window to begin with.
Also, if it *becomes* necessary to delay launching utilities, I'd need to go back to starting DF first anyway, putting us back at square one.
It's worth mentioning that the current default is to not close the launcher when launching DF, which doesn't cause any problems with DFHack (until the launcher is closed, that is).
The fundamental issue is that DFHack needs access to a terminal while running, and there's (apparently) no way to guarantee that. While the
specific problem of spamming the terminal only happens if you close the launcher while DFHack is running, it's only a symptom of the deeper problem. When there's no terminal (e.g. when using a pre-built executable), DFHack outright refuses to launch then.
Did you check $TERM environmental variable?
$TERM specifies terminal
capabilities, it does not specify the terminal executable itself. For example, on my primary Linux VM (Mint 15/MATE), it gets set to xterm (which is not installed, and does not have an alias in path).
subprocess.Popen() in python - doesn't that launch external process? This should open terminal and keep it opened even if you close pyLNP
It spawns a process that will keep running when PyLNP is closed, yes, but it does not spawn a new terminal window, and DFHack breaks if it doesn't have a terminal window (or loses exclusive access to one).
python 2 and 3 - is there specific reason to keep pyLNP compatible with py2?
Like Dricus said, the ability to build executables is one of them, but it also increases the likelihood that the user can use any existing Python installation.