.. @+leo-ver=5-thin .. @+node:maphew.20120709214653.1537: * @file Notes.txt .. @@language rst --- To Do --- ... or at least think about .. @+others .. @+node:maphew.20120622231339.1525: ** ---- Command line parsing ---- I have now spent several hours over several sessions looking at various methods and modules which might be leveraged to move apt from it's current monolithic mostly procedural architecture to something easier to work on and understand. Unfortunately, I don't understand most them, they live well above my skill level. So the goal here is to pick the one most likley to get some traction and succeed -- for me -- which is not necessarily "the best" for the true pythonistas at large. Now that reconnassance and a few tester scripts have been done, I've decided the 1st one I'll put serious energy into is **Plac**. Let's see how far I can get with it. .. @+node:maphew.20120622231339.1529: *3* -- Cliff -- http://cliff.readthedocs.org/en/latest/index.html - from the redoubtable Doug Hellman, a framework for building commandline programs that presents a unified interface for users but allows the backend to be organized and sorted as works for the devleopers. Meaning "apt setup" could be setup.py called by apt; easier separation and encapsulation, at least in theory. Easier for me to grasp the broad outlines of cliff than `argparse`, but still leaves my head swimming. The prospect of being able to have an interactive shell is *very* enticing. For years I've pondered building a wrapper script around `gdal` as I'm forever forgetting if it's `gdal_warp` or `gdalwarp` and if coordinate pairs start bottom left or top left (answer: it depends on which gdal prog...). This isn't _necessary_ for apt, but it _would_ be nice to have tab completion of package names, and it would be more efficient to use one CLI system for all my projects. .. @+node:maphew.20120622231339.1530: *3* - Docopt - https://github.com/docopt/docopt - Love the idea! Generate the argument and option parser from a single well written easy to read docstring, that follows the format that command line programs have been using for **decades**. """Naval Fate. Usage: naval_fate.py ship new ... naval_fate.py ship move [--speed=] naval_fate.py ship shoot Options: -h --help Show this screen. --version Show version. --speed= Speed in knots [default: 10]. --moored Moored (anchored) mine. --drifting Drifting mine. """ from docopt import docopt if __name__ == '__main__': arguments = docopt(__doc__, version='Naval Fate 2.0') print(arguments) .. @+node:maphew.20120622231339.1531: *3* - Plac: Parsing the Command Line the Easy Way - http://plac.googlecode.com/hg/doc/plac.html - easier to understand than Cliff, longer development history than Docopt, py 2.3 thru py 3, definitely has broader reach. Oooh, it has an interactive shell mode! The docs and examples are just one great big html page, nice to have it all at once, but makes it difficult to reference different sections at the same time. Not my usual method, but I could get over it. It looks like this might be the right module for me. Apparently simple enough to get usable results soon, and lots of head room to expand, probably more than I'll ever need. .. @+node:maphew.20120622231339.1532: *3* -- Others -- untested, not really looked at, Stack Overflow likes it: https://bitbucket.org/mchaput/baker/overview .. @+node:maphew.20120531113758.1779: ** ---- Features ---- I'd like to have an "apt remove -all" command (and perhaps "apt install -all"). One approach would be to simply list ./etc/setup/*.lst.gz and remove each. Another would be to leverage the package system and create dummy packages that simply include/exclude everything. One advantage of this method is alternate collections, e.g. Express, Developer, Mapserver, etc. (come to think of it, why doesn't setup.exe's Express option use this?) Be nice to list files for a package, e.g. "apt files package" ---> implemented as "apt listfiles", but only works for packages already installed. No easy way around this unless/until the server stores the equiv. of etc/setup/foobar.lst.gz wbnif to have a reverse requires: "What packages require python?" Remember to think about how output of commands might want to be used, e.g. piped to another program. "apt requires gdal-python" spits out a vertical list, but a horizontal row works better as input into other things sometimes ("libtiff libjpeg12 netcdf"). libtiff libjpeg12 netcdf Think about modifying the functions so they return values, which can then be potentially used by other functions, instead of the present just reporting the results to screen. .. @+node:maphew.20120622231339.1527: ** ---- Distribution ---- build package test locally upload to server (sftp://download.osgeo.org) make new setup.ini (http://upload.osgeo.org/cgi-bin/osgeo4w-regen-testing.sh) ((take snapshot of local o4w filesystem)) apt update apt new apt upgrade ((compare o4w filesystem with snapshot)) v0.0-4 - first pkg attempting to use apt.exe as primary means of invoking apt. It includes apt.py as apt-dev.py. .. @+node:maphew.20120622231339.1528: ** ---- AptExe --- Improve build and upload system so it's not so much work to create a new release. (would enable upgrade/replace python & self) Is it possible to make the .exe smaller? No, not really, not without building diff dists for each machine type (and even that is dubious). pyinstaller supports "Selectable executable icon.", maybe apt is ready for an icon? .. @+node:maphew.20120804225723.1549: ** --- Testing --- No test harness as yet, but here are some of my user-side testing methods. Two lightweight packages for quick testing of install and remove without a lot of dependencies are 'iconv' and 'curl'. apt install iconv curl apt remove iconv curl It's important to test both single and multiple package installs. .. @-others .. @-leo