Missing migration.ini does weird things to dependencies

[Drahflow]

We created migrations by hand, i.e. just mkdir plus add some .sql files. These directories had no migration.ini files in them. Except one, which specified a dependency. Nomad took this dependency and carried it over to other(!) migrations. This in turn lead to a stack overflow when trying to apply the depended-upon migration, because it claimed to depend on itself.

Yet, the migrations without migration.ini individually applied quite fine, i.e. the actual behavior of nomad differed between applying the migrations one-by-one and all-at-one.

Minimal example:

migrations % find
.
./0
./1
./2
./2/migration.ini
./nomad.ini
migrations % cat 2/migration.ini
[nomad]
dependencies = 1
migrations % nomad apply -a
<many, many lines omitted>
  File "/some-project.migrate/lib/nomad/repo.py", line 22, in inner
    f(self, *args, **kwargs)
  File "/some-project.migrate/lib/nomad/repo.py", line 207, in apply
    dep.apply(env=env, fake=fake)
  File "/some-project.migrate/lib/nomad/repo.py", line 22, in inner
    f(self, *args, **kwargs)
  File "/some-project.migrate/lib/nomad/repo.py", line 207, in apply
    dep.apply(env=env, fake=fake)
  File "/some-project.migrate/lib/nomad/repo.py", line 22, in inner
    f(self, *args, **kwargs)
  File "/some-project.migrate/lib/nomad/repo.py", line 207, in apply
    dep.apply(env=env, fake=fake)
  File "/some-project.migrate/lib/nomad/repo.py", line 22, in inner
    f(self, *args, **kwargs)
  File "/some-project.migrate/lib/nomad/repo.py", line 207, in apply
    dep.apply(env=env, fake=fake)
  File "/some-project.migrate/lib/nomad/repo.py", line 22, in inner
    f(self, *args, **kwargs)
  File "/some-project.migrate/lib/nomad/repo.py", line 206, in apply
    if not dep.applied:
  File "/some-project.migrate/lib/nomad/repo.py", line 160, in applied
    return self.name in self.repo.appliednames
RuntimeError: maximum recursion depth exceeded while calling a Python object

[Drahflow]

Apropos: An (IMHO) very sensible default behavior would be to have migrations without migration.ini depend per-default on all lexicographically smaller migrations.

[piranha]

I'm not exactly sure why I didn't do that. :) I'm not sure when I'll get to do that myself (I guess you can see that), but I'm accepting contributions! :)