Issues

Issue #95 new

__init__.py file in versions directory

Sylvain Prat avatarSylvain 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 (9)

  1. Mike Bayer

    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

    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. Mike Bayer

    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. Log in to comment
Tip: Filter by directory path e.g. /media app.js to search for public/media/app.js.
Tip: Use camelCasing e.g. ProjME to search for ProjectModifiedEvent.java.
Tip: Filter by extension type e.g. /repo .js to search for all .js files in the /repo directory.
Tip: Separate your search with spaces e.g. /ssh pom.xml to search for src/ssh/pom.xml.
Tip: Use ↑ and ↓ arrow keys to navigate and return to view the file.
Tip: You can also navigate files with Ctrl+j (next) and Ctrl+k (previous) and view the file with Ctrl+o.
Tip: You can also navigate files with Alt+j (next) and Alt+k (previous) and view the file with Alt+o.