__init__.py file in versions directory

Issue #95 resolved
Sylvain Prat
created an issue

Today, it's not possible to add an (empty) __init__.py file inside the versions directory since it is considered as a migration script and as it does not contain the proper revision and down_revision variables, alembic stops working.

However, allowing us to use a __init__.py file inside this package would facilitates the packaging: setuptools and distribute do not package the folders not having a __init__.py file automatically, so the migration scripts end up not packaged by default. We can still use the MANIFEST.in file to add them, but it's a little annoying since we may forget to do that.

This may have some side effects though: what if someone put some code in __init__.py? Should the code be taken into account in all migration scripts?

May be related to issue #91, but we don't ask exactly the same thing.

Comments (16)

  1. Michael Bayer repo owner

    it is related to #91 to the degree that we'd be concerned with what's in the __init__.py, but this specific issue is more about the discussion in issue #72. Seems like I left off with, "sure, I don't mind getting it to ignore __init__.py".

    But given the proposals in #91, it seems like there's a choice whether we decide to ignore __init__.py, or we change Alembic to actually import the versions directory more like a package - even though #91 is more about each version as a package, seems like we should think about what an __init__.py means here. right now we pull in the version files using imp.load_source() on each file individually.

    The #91 change isn't happening on my end anytime soon, whereas just ignoring __init__.py is a quick fix.

  2. Sylvain Prat reporter

    Exact, my feature request is more about the discussion in #72 and I don't really need what's described in #91 - seems strange to me to have so much code in a migration script.

    I'm in favor of ignoring the __init__.py file for now, but the real question is: should it be ignored silently?

    Actually, since you don't generate an __init__.py by default, there's no incentive to put code there. So, if the user choose to add one, we can assume he knows what it does and just ignore the __init__.py file silently. But, like I said before, the migrations scripts will not be packaged by default in this setup.

    I would prefer the __init__.py file to be there by default so we don't forget to package the versions files, but I guess we should warn the user that he should not add code in the __init__.py file, maybe by putting a big uppercase warning comment in the __init__.py file?

    Or maybe this __init__.py file should just be the new env.py?

  3. Michael Bayer repo owner

    I don't see the need for env.py to move like that, it's a separate and very specific concern versus the environment in which migration files run. an __init__.py would theoretically include helpers that migration scripts use but really, I put those helpers in my application elsewhere (usually in myapp/model/migration/).

    at the moment the thinking is just that we'll let __init__.py be there so as to take advantage of a behavioral artifact of distutils, but otherwise it's a do-nothing file. Im sure people will start asking for it to be functional at some point, but we can address that later.

  4. techno techne

    It would be nice if there were a specific warning explaining that there shouldn't be an __init__.py in this directory, if you put one in there. I was just very confused (my IDE had created this file automatically at some point). If you didn't do this on purpose, it's a confusing error message.

  5. techno techne

    Yes, I anticipated that. But it's an exceptionally good IDE, with generally reasonable assumptions (PyCharm). It didn't do this out of nowhere, it's because I used one of its refactoring gestures to move my migrations directory. That's when the __init__.py was created.

    The point isn't my IDE. The point is that it's reasonable to assume that a folder of Python modules could also be made into a Python package by adding an __init__.py. In most cases, this will not break things. So people (or IDEs) might do it, and maybe it'd be good to correct their error fast.

  6. techno techne

    OK, that's even better. I read "at the moment the thinking is just that we'll let init.py be there" and thought you meant this issue would not be addressed in any way... should have read the whole comment and the rest of the thread. Thanks, sorry to waste your time!

  7. Log in to comment