Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

add --package flag to alembic init to support building as package #463

Closed
sqlalchemy-bot opened this issue Oct 31, 2017 · 10 comments

Comments

@sqlalchemy-bot
Copy link

commented Oct 31, 2017

Migrated issue, originally created by Luke Schlather (@lukeschlather)

When I run alembic init, it generates alembic.ini, alembic, and alembic/versions/ .

I run this in a namespaced directory (e.g. database) under a python package. It would be nice if alembic automatically detected that it was being created within a python package, and modified the Manifest, and/or added init.py files to ensure it is distributed along with the package.

As an example, suppose I had a structure like:

#!

* mypackage
** setup.py
*** database 

If I were to run "alembic init" in the database directory, it would be nice if alembic init detected the setup.py in the root of the project, created a MANIFEST.in if need be, and created init.py files so it instead looks like:

#!

* mypackage
** setup.py
** MANIFEST.in
*** database 
**** alembic/__init__.py
**** alembic/versions/__init__.py
@sqlalchemy-bot

This comment has been minimized.

Copy link
Author

commented Oct 31, 2017

Changes by Michael Bayer (@zzzeek):

  • edited description
@sqlalchemy-bot

This comment has been minimized.

Copy link
Author

commented Oct 31, 2017

Michael Bayer (@zzzeek) wrote:

I'd be more comfortable with a flag --update-manifest. Way way less risky and surprising. what do you think?

@sqlalchemy-bot

This comment has been minimized.

Copy link
Author

commented Oct 31, 2017

Luke Schlather (@lukeschlather) wrote:

Everyone I work with (including me) is continually surprised when they deploy a new package and alembic fails. I think --update-manifest is a decent place to put the feature, but I know my company's documentation is going to say to always use the option.

I do get the worry, since our packaging setup certainly isn't universal and I'm sure there are cases where updating the manifest could have unexpected results. Also the logic around update-or-create MANIFEST.in could be a little surprising, though simply appending if exists is probably fine.

@sqlalchemy-bot

This comment has been minimized.

Copy link
Author

commented Oct 31, 2017

Michael Bayer (@zzzeek) wrote:

Um...why aren't you using a wildcard in your MANIFEST.in? there's no need to add individual __init__.py files, and also alembic init doesn't create any __init__.py files anyway. were you looking for individual line items for every new version file?

@sqlalchemy-bot

This comment has been minimized.

Copy link
Author

commented Oct 31, 2017

Michael Bayer (@zzzeek) wrote:

oh I see you want it to create __init__.py files. These need to all be options, preferably one that uses a package name for "script_location" in alembic.ini.

@sqlalchemy-bot

This comment has been minimized.

Copy link
Author

commented Oct 31, 2017

Michael Bayer (@zzzeek) wrote:

like this:

alembic init --package myapp.foo  

it will then use PYTHONPATH and import to figure out where "myapp.foo" is supposed to be and will generate the entrypoint in alembic.ini script_location, and make sure whatever __init__.py is necessary.

@sqlalchemy-bot

This comment has been minimized.

Copy link
Author

commented Oct 31, 2017

Luke Schlather (@lukeschlather) wrote:

alembic init --package myapp.foo

Sounds good. In that case it seems more reasonable to me to make --update-manifest assumed, since it shouldn't have to do as much guessing.

@sqlalchemy-bot

This comment has been minimized.

Copy link
Author

commented Nov 12, 2017

Changes by Michael Bayer (@zzzeek):

  • changed title from "alembic init should ensure it is packaged properly" to "add --package flag to alembic init to support buil"
@zzzeek

This comment has been minimized.

Copy link
Member

commented Sep 19, 2019

looking at this again, trying to figure out what to do.

  1. I really dont think it's appropriate to generate a MANIFEST.in as Alembic makes no assumptions about what kind of environment it's being run within.

  2. Similarly, editing MANIFEST.in would be hugely surprising to most people, not to mention error prone, and also unnecessary if there are __init__.py files present. Otherwise, why doesn't "sphinx init" for example also search for or edit MANIFEST.in. This would be really inappropriate since a code generation tool should not be trying to also be a packaging tool, unless it's actually being used as a packaging tool.

  3. I know above I said I'd search in sys.path but I don't know why I said that, sys.path can have any number of paths within it.

What I can do, that is easy and is the kind of thing that people ask for, is that if you say "--package", it simply puts the two __init__.py files there as well, but everything else is the same. going to do that for now.

@sqla-tester

This comment has been minimized.

Copy link
Collaborator

commented Sep 19, 2019

Mike Bayer has proposed a fix for this issue in the master branch:

Add --package flag to write init.py files https://gerrit.sqlalchemy.org/1471

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
3 participants
You can’t perform that action at this time.