Matthias Beyer
0cdeeb4c55
We must return an error if the file is not found here. This is because if we unwrap() here, we panic if the store action was Store::retrieve() and there wasn't a file there. We then unwrap() on None and panic because of this, causing all other tests to panic as well because the Mutex gets corrupted. The store handles FileNotFound errors on its own, so it is safe to return the error here. |
||
|---|---|---|
| .imag-documentation | ||
| bin | ||
| doc | ||
| imag-bookmark | ||
| imag-counter | ||
| imag-diary | ||
| imag-link | ||
| imag-notes | ||
| imag-ref | ||
| imag-store | ||
| imag-tag | ||
| imag-todo | ||
| imag-view | ||
| libimagbookmark | ||
| libimagcounter | ||
| libimagdiary | ||
| libimagentryedit | ||
| libimagentryfilter | ||
| libimagentrylink | ||
| libimagentrylist | ||
| libimagentrymarkdown | ||
| libimagentryselect | ||
| libimagentrytag | ||
| libimagentryview | ||
| libimagerror | ||
| libimaginteraction | ||
| libimagnotes | ||
| libimagref | ||
| libimagrt | ||
| libimagstore | ||
| libimagstorestdhook | ||
| libimagtimeui | ||
| libimagtodo | ||
| libimagutil | ||
| tests | ||
| .editorconfig | ||
| .gitignore | ||
| .travis.yml | ||
| CONTRIBUTING.md | ||
| default.nix | ||
| imagrc.toml | ||
| LICENSE | ||
| Makefile | ||
| README.md | ||
imag - imag-pim.org
Imag is a CLI PIM suite you can integrate in your tools of choice (Editor, MUA, RSS reader, etc etc).
Please contribute!
We are looking work contributors!
There is always a number of complexity/easy tagged issues available in the issue tracker you can start with and we are open to questions!
Feel free to open issues for asking questions, suggesting features or other things!
Also have a look at the CONTRIBUTING.md file!
Goal
Our goal is to
Create a fast, reliable, forwards/backwards compatible commandline personal information management suite which covers all aspects of personal information management, consists of reusable parts and integrates well with known commandline tools.
We try to accomplish these requirements:
- "fast": We use the awesome, fast and safe programming language "Rust"
- "reliable": We try to test every aspect of our software. Our build process ensures that the build breaks whenever a library interface changes and the modules which use the library are not updated.
- "forwards/backwards compatible:" Our (plain text) on-disk data format and storage library both ensure that incompatibilities are captured and resolved (using semver)
- "commandline": We ensure that everything can be done by commandline calls, for some modules there might be a curses-like UI, but there are no graphical clients and there never will be any within this codebase. We use clap for commandline-interface building and we try to keep the interface easy and consistent between modules.
- "personal": We store everything as plain text in a store inside the users
$HOMEdirectory. There will be a version-control (most surelygit) hook integrated to sync between several machines. There are no multi-user features included or planned at the time of writing. - "information management": We want to give the user the possibility to put every single information about their personal lives into the store and we try hard to provide a sane interface to query and retrieve data from this database.
- "covers all the aspects of personal information management": We want to
provide modules for:
- contact management
- calendar
- diary
- notes
- personal wiki
- news (rss)
- passwords
- images
- music
- movies
- personal project management
- podcast management
- ledger
- bibliography management
- ... and many, many more.
- "constists of reusable parts": Every functionality is implemented as library. The binaries we ship are just commandline-interace-to-library-interface translators
- "integrates well with known commandline tools": We do not re-invent the wheel.
We do not implement "yet another password manager", but use
the standard unix password manager, do not
implement a news reader, but use newsbeuter,
do not reimplement a mail reader, etc etc.
We do not copy images, movies or other data to the store but "link" them into
the store, so you can use imag tools to query and access this data, but still
live with your beloved commandline apps. We do not want to duplicate work but
reuse as much as possible.
You don't like one of the applications we use (for example
passas password manager)? Sure, feel free to submit patches so the user is able to switch the used tool, as long as it doesn't break the workflow. We will happily merge them!
Current state of development
This application is in really early development.
We have implemented the very core of the system, though some more utility work is to be done. We have the store working, a hooks API and some default hooks are in development. Basic features like tagging and linking entries is possible as well as viewing entries. Some small things are implemented, like a note-taking module, a basic diary module, a counter module and a bookmark module. These modules contain basic features and are subject to change. More modules are about to be implemented.
Though, the very core of the system is stable and nothing prevents you from contributing and implementing a module.
Building/Running
Here goes how to try imag out.
Building
By now, there are several targets in the Makefile, fulfilling following roles:
allIs the default and builds every crate in debug mode. This is the same as traversing every directory yourself and callingcargo buildin it. To build a single crate, callmake <crate>, for examplemake imag-storerelease, as the name implies, builds every crate in release mode. Following the example above, to buildimag-storein release mode, callmake imag-store-release.installwill install all binary crates to the default installation root (seeman cargo-install). To install a single module, runmake <module>-install, again, for example:make imag-store-installbin/libare separate targets for either building all binaries or libraries.lib-testrunscargo testfor all libraries. For testing a single library, runmake test-libimagstorefor example.cleanwill runcargo cleanin every crate. Again, for cleaning a single crate, usemake imag-store-cleanfor example.- to build only the
imagbinary, use the targetimag-bin(imag-bin-releasefor release build,imag-bin-updateforcargo updateing,imag-bin-cleanforcargo cleaning).
Running
To test out a single module, simply using cargo run -- <options> in the
respective directory will do the trick. For using it "normally", install the
binaries as described above, as well as the imag-binary:
$> make install
The installation root of the binaries (a.k.a. where they are installed to), may
not yet be in your $PATH. To see, where this installation root is, check out
man cargo-install. To change the $PATH in bash:
$> PATH=$PATH:~/.cargo/bin
$> imag --help
To test, simply add --help to one of the above commands:
$> imag counter --help
Please note that $PATH will be reset in a new shell. To make these changes permanent, see the User Guide of your shell.
Documentation
For detailed information, please read the documentation (You can either read the Markdown files or compile it to HTML/PDF using pandoc). Developer documentation is also available online on github.io.
Please note that the documentation is work in progress as well and may be outdated.
Contact
Have a look at our website where you can find some information on how to get in touch and so on.
Feel free to join our new IRC channel at freenode: #imag or our mailinglist.
License
We chose to distribute this software under terms of GNU LGPLv2.1.
This decision was made to ensure everyone can write applications which use the imag core functionality which is distributed with the imag source distribution.