Store paths relative to the database location when using -D about tmsu HOT 11 CLOSED

I'll take a look on Monday. You may be better if using a local database which is initialised using the 'init' subcommand though, which definitely uses relative paths. Take a look at 'tmsu help init'.

I'll remind myself what using -D does and get back to you though.

from tmsu.

Thanks. Using tmsu init works, the paths are relative, I'm not sure why TMSU needs a whole new directory for the DB, though.

from tmsu.

@tsudoko
Although I can't personally comment on Paul's motivation, segregating data for different applications by putting them in their own directory seems to be the current convention.

It also means any future expansion will be cleaner, which personally I appreciate (I'm storing a file 'tagbuffers.json' in there myself, which tracks recently applied tagsets for quick reapplication through a GUI)

from tmsu.

The motivation for the directory was future extensibility. However I could
easily change it to not create the directory (but still support it if used).

Unfortunately I packed the wrong PSU this morning so have no laptop (the
battery is shot). I'll take a look at the absolute paths issue on Thursday.
On 5 Oct 2015 01:00, "0ion9" [email protected] wrote:

@tsudoko https://github.com/tsudoko
Although I can't personally comment on Paul's motivation, segregating data
for different applications by putting them in their own directory seems to
be the current convention.

It also means any future expansion will be cleaner, which personally I
appreciate (I'm storing a file 'tagbuffers.json' in there myself, which
tracks recently applied tagsets for quick reapplication through a GUI)

—
Reply to this email directly or view it on GitHub
#49 (comment).

from tmsu.

The current implementation will store paths relative to the database root (the directory in which the .tmsu directory lives) providing:

1. The file is under the database root.
2. The files is one directory up from the database root.

In other cases the absolute path is used.

I can could change this, such that all paths are stored relatively, but it could lead to relative paths with a lot of ../../.. resolution going on, which I imagine could be a bit fragile.

Thoughts?

from tmsu.

Anybody have any input on how they would like paths to be stored for the default database?

Perhaps it is time we retired the concept of the default database altogether and use only databases created with the init command?

from tmsu.

Perhaps it is time we retired the concept of the default database altogether and use only databases created with the init command?

👍 . There are some complications involved when you want to tag something outside of your privileges - eg. you can't just cd /etc;tmsu tag foo bar unless you are root, you would have to cd to a directory that has an inited db and then do tmsu tag /etc/foo bar. But overall it'd make TMSU easier to understand.

Are there any people currently using TMSU who would have problems with such a simplification?

from tmsu.

OK, what I'll do then is this:

1. Remove automatic creation of the default database.
2. Add a message (to inform the user to run init) if no database can be found.

I'll preserve support for the default database though, so that existing databases continue to work and in case anyone wants to manually create one.

from tmsu.

@0ion9 In the case of permissions, it would be possible to create a database elsewhere and manually use it using the -D option.

from tmsu.

@oniony
That's true, and suitable for aliasing if you want only one DB. If you want more than one DB, either writing a shell function or doing the workaround I specified seems more apt.

from tmsu.

Cool. I'll close this and raise a new ticket #55 .

from tmsu.