Skip to content

Commit

Permalink
Tune apt info reporting, esp. for "installed version"
Browse files Browse the repository at this point in the history 
...and, I realize I've muddled and confused things. The main data tables
need clear separation, "package names and version available on server"
and "what is actually locally installed". The old functions actually
maintained this better before I started messing with them. (In my
defense, they were horribly opaque tho'.)

For instance I grew the idea that `apt ball` reconstructed the version
name from the currently available archive filename on the server. Yes,
get_ball() constructs from the filename, but not from the filename in
setup.ini, it's actually from the name in installed.db -- a crucial
difference!

TODO: rescue good parts of old functions, clearly separate local/server
info, dump overlapping dict records.
  • Loading branch information
@maphew
maphew committed Mar 31, 2015
1 parent 154f90c commit 4b9190f
Showing 1 changed file with 12 additions and 5 deletions.
17 changes: 12 additions & 5 deletions apt.py
View file
Original file line number Diff line number Diff line change
Expand Up @@ -218,12 +218,15 @@ def info(packages):
zip_size : 3763
md5 : c38f03d2b7160f891fc36ec776ca4685
local_zip: d:/temp/o4w-cache/setup/http%3.../shell-1.0.0-13.tar.bz2
installed: True
install_v: 1.0.0-11
Note: "local_zip" is best guess based on current mirror. (We don't record which mirror was in use at the time of package install.)
Notes:
- "local_zip" is best guess based on current mirror. (We don't record which mirror was in use at the time of package install.)
- "version" is from setup.ini, what is available on the mirror server
- "install_v" is the version currently installed
'''
#AMR66:
if isinstance(packages, basestring): packages = [packages]
#if type(packages) is str: packages = [packages]

if not packages:
help('info')
Expand All @@ -248,12 +251,16 @@ def info(packages):
'installed']
for k in fields:
print('{0:9}: {1}'.format(k,d[k]))
if d['installed']:
print('{0:9}: {1}'.format('install_v',d['install_v']))

if debug:
# This guaranteed to print entire dict contents,
# but not in a logical order.
print '\n----- Complete get_info() dict -----'
for k in d.keys():
print('{0:8}:\t{1}'.format(k,d[k]))
print '-' * 36
#@+node:maphew.20100223163802.3722: *3* find
def find(patterns):
'''Search installed packages for filenames matching the specified text string.'''
Expand Down Expand Up @@ -1474,8 +1481,8 @@ def get_info(packagename):

if packagename in installed[0].keys():
d['installed'] = True
d['installed_ver'] = version_to_string(get_installed_version(packagename))
# don't like long key name, but...
d['install_v'] = version_to_string(get_installed_version(packagename))
# don't like key name, but...
else:
d['installed'] = False

Expand Down

4 comments on commit 4b9190f

@amr66
Copy link
Contributor

@amr66 amr66 commented on 4b9190f Mar 31, 2015

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As being relatively new to apt programming and English not my native language, I often thought about the structure of apt and the names of functions and variables.

Difficult to see through is the length of code, so I would suggest to split it in functional or logical parts. I saw this in different github projects, that multiple python files exist, but only one complete file was the output for installing - never tried out, if a ide/tool supports such things? On the other hand, importing them as modules shouldn't be a problem either.

I really don't like all the globals, because one can never be sure if and where they are initialized, even you don't see they are global. And I like to have a main(argv) function and a short global section.

One way out of this is using classes, as they have separated name spaces and we could name similar variables equally - same with separated modules.

My proposal:
"apt" is the name of the program, handling the commands, checking options, environment: it's our User Interface.
"setup" describes the superior thing of apt. It is the connection between server and local stuff. As a command ('setup') it initialises the installation. It knows, which setup files will be stored and where to find them ('setup_rc: rc=resources: wrong word right action?').

"installation" describes the output of apt well, as the local part of setup, it deals with the local install (as a command) of packages, does the post_install, reports errors and success of installed packages

"repository" is often used for what osgeo4w download server is, it is the availability of "ressources", it has mirrors, several trees ("architectures") and holds downloadable setup files and packages

"packages", I liked to encapsulate them, containing the metadata and information about the 'content'. They could have a server and a local "status", mainly a version and a installed flag.

It's not mandatory to realize a class structure, but, as you said, words should be clear and intuitiv. As I wrote, its a proposal, hoping to give some impulse.

@maphew
Copy link
Owner Author

@maphew maphew commented on 4b9190f Mar 31, 2015

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Your thoughts and perspective are very welcome. I tend to wordy and flowery language, which I imagine makes me difficult to understand sometimes, coming from another mother tongue. Please don't hesitate to let me know when I'm confusing more than illuminating.

Doing something about the global "pollution" has been a main drivers for all the changes I've made in the last year or so. I've tackled it in very small pieces, striving to maintain an always functional program. This comes after more ambitious attempts to start from the top down didn't go very well (see wildlands folder). Perhaps better said as: I learned a whole lot, but didn't emerge on the other side with much working and reusable code!

Thinking about how to divide

I see the major categories as:

  • user interaction - commands, parameters, reporting
  • information - setup_ini, install.db, file system (bin, apps, cache, ...)
  • actions - do_install, do_download, do_remove
  • helpers - getters, parsers, utilities (actually just a subset of actions?)

Naming the user interaction category/class/module "apt" makes sense to me. Not sure about the others.

Of these user interaction which is most broken. I've sampled a number of alternative parameter/argument approaches and am leaning strongly towards Click. My loose game plan has been to make all the top level commands (those reported by apt help) bug free, or at least reliable most of the time, issue a stable release, and then start a "proper argument handling" branch. However after last night I'm thinking Clarify data model muddle (#35) might be more important. Or maybe they're just different facets of the same rough gem.

Either way getting to a stable release is my next immediate goal (without significant restructuring that will delay even longer).

Modules vs Classes: I've used classes once or twice but don't understand them very well, so tend to avoid. I don't have a feel for when a class should be chosen over a module or vice versa. I'm quite willing to explore using classes, but likely wouldn't make a good architect for building them at this stage in my learning. (In other words: make a fork, I'll try and eat with it!)

@amr66
Copy link
Contributor

@amr66 amr66 commented on 4b9190f Mar 31, 2015

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

+1
that would be a big branch :-)

@amr66
Copy link
Contributor

@amr66 amr66 commented on 4b9190f Apr 1, 2015

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

however, I started testing a first oo-version, began it some weeks ago...

Please sign in to comment.