Desiderata API

[szaghi]

@cmacmackin

I start writing some idea about I would like FLATPack looks like. This is just a memo where writing working in progress thoughts:

• client API:
  • mantaing a local plain text database file of installed packages:
    • plain (flat) text allow many awesome things like sharing between us configuration, easy crestion of awesome lists...;
    • data saved into the database: mandatory should be package name and installation path and dependecies;
  • query the remote user defined repositories for searching packages;
  • resolve conflicts like the same package on different repository (prompting the user to make non ambiguos choice);
  • install and unistall packages handling dependencies, allowing options for clean not still necessary dependecies;
• server API:
  • not a centralized sever (not a server at all), but just a remote git repository exposing a FLATPack database where packages are classified and which can be interrogatdd by client FLATPack:
    • such a database list packages, their dependencies (that are copied on client database when a package is installed) and they can installed (compiled from sources, building tool yo be used, binary install...).

For the database language/syntax I suggest json: Python has a lot of modules for json and now also Fortran has a great one :-) Json is a good compromise: it is still human readable, but it can handle more complex structures than INI file gor example, moreover json is a well establidhed standard.

I like the idea to have github repositories collecting database of Fortran packages that users can interrogate to easy install them.

These are just starting ideas that tonight come to me...

[cmacmackin]

This looks like a good start and is broadly in line with what I was thinking.

[cmacmackin]

Not really API, but I've started to put some thought into how to divide up the task into different modules and objects. As always, I'm happy to hear feedback. In particular, I have a tendency to make objects and modules that are too large, so if people can think of further ways to subdivide work then that would be great.

• args: Parses command line arguments to get instructions from user
• config: Parses a config file for information about where to install stuff, etc.
• instance: Object representing where to build and install software as well as where to look for libraries/mod files/headers for this run of FLATPack. Would make it easier to add the ability for people to have multiple locations (a bit like virtualenvs in Python).
• local: Object(s) or database representing what is currently installed by FLATPack
• package: Objects representing a given software package, its dependencies and the like
• compile environment: Objects representing (and performing) the compilation of a package for a particular compiler (and version) with particular flags. Might want to break this up into separate modules depending on build system.
• installer: Places files in the necessary installation paths. This would include binaries, mod files, headers, and documentation.
• Methods for the various subcommands that FLATPack would have:
  • install
  • compile
  • update
  • upgrade
  • remove
  • search
  • help
  • submit? (A command to submit a user's own package to the database?)
  • flag? (Notify that a package is behaving erroneously)

[szaghi]

👍

Addendum: submit is nice, but... I suggest to strongly take advantage of git (e.g. install => git clone package locally + eventual build + copy into final local path) thus think to submit to something related to a pull request to the remote database repository for adding user-submitted-package... exploiting git could be the key.

[milancurcic]

Agreed, whatever existing functionality is provided by git should be used.
I like Chris' list of flatpack methods so far. Submit and flag could
probably be handled by Github issues on a hypothetical flatpack-repo page
(the one that Stefano mentioned as the "server", containing all supported
package metadata).

Chris, I don't quite understand the distinction between "compile" and
"install"? Is the difference analogous to "make" and "make install" where
the latter simply copies the compiled object/library/mod files to a prefix
directory?

Another flatpack method I would find quite useful would be "list" - lists
installed packages.

On Thu, Jul 2, 2015 at 4:13 PM, Stefano Zaghi [email protected]
wrote:

[image: 👍]

Addendum: submit is nice, but... I suggest to strongly take advantage
of git (e.g. install => git clone package locally + eventual build +
copy into final local path) thus think to submit to something related
to a pull request to the remote database repository gor adding
use-submitted-package... exploiting git could be the key.

—
Reply to this email directly or view it on GitHub
https://github.com/Fortran-FOSS-Programmers/FLATPack/issues/2#issuecomment-118153297
.

[szaghi]

👍 for list method

Also clean for removing unnecessary dependency/orphans

[cmacmackin]

I agree, we should use whatever existing functionality Git has. What I was (vaguely) thinking could be done with those two commands is to use git/GitHub's public API. If that were to be something we'd do then it would likely be several releases down the road.

@milancurcic Yes, that would essentially be the difference between install and compile. Also, whereas install would probably remove all of the stuff left over from compiling (source and object files etc.) compile wouldn't.

List and clean both sound like good methods to have.

[szaghi]

@cmacmackin

I am reading your last push. Great job! I am studying your layout: I am not a pythonish programmer, many things remain obscure, I hope to improve my knowledge with your help :-)

[cmacmackin]

Well, I don't know if I'm much better than you are.

On 03/07/15 10:13 AM, Stefano Zaghi wrote:

@cmacmackin https://github.com/cmacmackin

I am reading your last push. Great job! I am studying your /layout/: I
am not a pythonish programmer, many things remain obscure, I hope to
improve my knowledge with your help :-)

—
Reply to this email directly or view it on GitHub
https://github.com/Fortran-FOSS-Programmers/FLATPack/issues/2#issuecomment-118346182.

Chris MacMackin
Saint Mary's University
Curriculum Vitae http://ap.smu.ca/%7Ecmacmack/CV.pdf

[zbeekman]

What if instead of compile and install methods we have something like install or build and link, activate or deploy (or install could build and link/deploy). I’m writing a separate issue now with the proposed directory structure and mechanics, right now.

[milancurcic]

@cmacmackin Great work on the layout so far. I am curious about why you decided to have a separate file/module for each command? At this point it looks like an unnecessary layer of complexity, but you may have something in mind with that approach. I thought that defining the command functions in a single module commands.py would be the obvious simple way to go. Don't mean to be a gadfly but trying to understand the general direction flatpack is heading :).

[cmacmackin]

Well, either way would work. I chose to do them all in their own files because I personally thought that was a bit tidier. Generally I prefer small files compared to large ones.

[milancurcic]

@cmacmackin 👍