feat: add native mcfly import support

[zampierilucas]

Description

This PR adds native import support for mcfly shell history, allowing users to migrate their mcfly history to Atuin with a single command: atuin import mcfly

Implementation

The implementation directly accesses mcfly's SQLite database without requiring the mcfly binary to
be in PATH.

• Cross-Platform Database Discovery: Automatically finds mcfly database across different platforms:
  • ~/.mcfly/history.db (legacy path)
  • ~/.local/share/mcfly/history.db (XDG default on Linux)
  • $XDG_DATA_HOME/mcfly/history.db (XDG custom)
  • ~/Library/Application Support/McFly/history.db (macOS)
  • %LOCALAPPDATA%\McFly\data\history.db (Windows)
• Complete History Import: Imports all fields from mcfly's commands table including timestamps, exit
  codes, working directories, and session information
• Session ID Mapping: Maps mcfly session IDs to UUIDs for Atuin compatibility(similar to zsh-histdb import)
• Custom Database Path: Supports --file option for importing from custom database locations

Testing

• Added unit tests with real SQLite database operations
• Tests cover: successful imports, empty databases, missing fields scenarios
• Added integration tests for the import process
• Tests cover: valid imports, invalid timestamps, empty history
• Cross-platform path detection testing

Overall, this is a much better implementation than the previous dump and import approach, as it preserves the mcfly metadata as well.

[zampierilucas]

Hi @ellie,
I noticed you were involved in review for other PRs, can you help me figure out I'm missing something to get this Mr reviewed? or should I have opened a 'feature request' first?

[ellie]

Apologies - I've been sick and had a lot on recently so have prioritized reviewing + releasing work either from prior contributors, or for PRs that are easier to review. We've had a bunch of issues from importer related PRs in the past, so these tend to need extra scrutiny.

Anyway. This generally looks good, but I'd prefer that we dropped the requirement on mcfly. If we could directly read the database that would be perfect! I would also accept reading the output of mcfly dump, without automatically running it. Some users might have workflows where they have the data, but do not have the binary in their path.

[zampierilucas]

Hi @ellie, hope you are doing better.

I've followed your suggestion a re-did the import from the db, instead of requiring the mcfly binary to dump as json, and It's pretty nice as now it preserves most of the mcfly metadata, and also allow to just specify --file db.path.