diff options
| -rw-r--r-- | .gitignore | 1 | ||||
| -rw-r--r-- | python-pytest-alembic.spec | 315 | ||||
| -rw-r--r-- | sources | 1 |
3 files changed, 317 insertions, 0 deletions
@@ -0,0 +1 @@ +/pytest_alembic-0.10.1.tar.gz diff --git a/python-pytest-alembic.spec b/python-pytest-alembic.spec new file mode 100644 index 0000000..741db4a --- /dev/null +++ b/python-pytest-alembic.spec @@ -0,0 +1,315 @@ +%global _empty_manifest_terminate_build 0 +Name: python-pytest-alembic +Version: 0.10.1 +Release: 1 +Summary: A pytest plugin for verifying alembic migrations. +License: MIT +URL: https://github.com/schireson/pytest-alembic +Source0: https://mirrors.nju.edu.cn/pypi/web/packages/71/d8/b166bae71d82f82c41cadb53ce4219ed9ecd4f1fcb4cf9719d2447aecc2c/pytest_alembic-0.10.1.tar.gz +BuildArch: noarch + +Requires: python3-pytest +Requires: python3-alembic +Requires: python3-sqlalchemy + +%description +``` +## The pitch +Have you ever merged a change to your models and you forgot to generate +a migration? +Have you ever written a migration only to realize that it fails when +there’s data in the table? +Have you ever written a **perfect** migration only to merge it and later +find out that someone else merged also merged a migration and your CD is +now broken!? +`pytest-alembic` is meant to (with a little help) solve all these +problems and more. Note, due to a few different factors, there **may** +be some [minimal required +setup](http://pytest-alembic.readthedocs.io/en/latest/setup.html); +however most of it is boilerplate akin to the setup required for alembic +itself. +### Built-in Tests +- **test_single_head_revision** + Assert that there only exists one head revision. + We’re not sure what realistic scenario involves a diverging history to + be desirable. We have only seen it be the result of uncaught merge + conflicts resulting in a diverged history, which lazily breaks during + deployment. +- **test_upgrade** + Assert that the revision history can be run through from base to head. +- **test_model_definitions_match_ddl** + Assert that the state of the migrations matches the state of the + models describing the DDL. + In general, the set of migrations in the history should coalesce into + DDL which is described by the current set of models. Therefore, a call + to `revision --autogenerate` should always generate an empty migration + (e.g. find no difference between your database (i.e. migrations + history) and your models). +- **test_up_down_consistency** + Assert that all downgrades succeed. + While downgrading may not be lossless operation data-wise, there’s a + theory of database migrations that says that the revisions in + existence for a database should be able to go from an entirely blank + schema to the finished product, and back again. +- [Experimental + tests](http://pytest-alembic.readthedocs.io/en/latest/experimental_tests.html) + - all_models_register_on_metadata + Assert that all defined models are imported statically. + Prevents scenarios in which the minimal import of your models in your `env.py` + does not import all extant models, leading alembic to not autogenerate all + your models, or (worse!) suggest the deletion of tables which should still exist. + - downgrade_leaves_no_trace + Assert that there is no difference between the state of the database pre/post downgrade. + In essence this is a much more strict version of `test_up_down_consistency`, + where the state of a MetaData before and after a downgrade are identical as + far as alembic (autogenerate) is concerned. + These tests will need to be enabled manually because their semantics or API are + not yet guaranteed to stay the same. See the linked docs for more details! +Let us know if you have any ideas for more built-in tests which would be +generally useful for most alembic histories! +### Custom Tests +For more information, see the docs for [custom +tests](http://pytest-alembic.readthedocs.io/en/latest/custom_tests.html) +(example below) or [custom static +data](http://pytest-alembic.readthedocs.io/en/latest/custom_data.html) +(to be inserted automatically before a given revision). +Sometimes when writing a particularly gnarly data migration, it helps to +be able to practice a little timely TDD, since there’s always the +potential you’ll trash your actual production data. +With `pytest-alembic`, you can write tests directly, in the same way +that you would normally, through the use of the `alembic_runner` +fixture. +```python +def test_gnarly_migration_xyz123(alembic_engine, alembic_runner): + # Migrate up to, but not including this new migration + alembic_runner.migrate_up_before('xyz123') + # Perform some very specific data setup, because this migration is sooooo complex. + # ... + alembic_engine.execute(table.insert(id=1, name='foo')) + alembic_runner.migrate_up_one() +``` +`alembic_runner` has a number of methods designed to make it convenient +to change the state of your database up, down, and all around. +## Installing +```bash +pip install "pytest-alembic" +``` + +%package -n python3-pytest-alembic +Summary: A pytest plugin for verifying alembic migrations. +Provides: python-pytest-alembic +BuildRequires: python3-devel +BuildRequires: python3-setuptools +BuildRequires: python3-pip +%description -n python3-pytest-alembic +``` +## The pitch +Have you ever merged a change to your models and you forgot to generate +a migration? +Have you ever written a migration only to realize that it fails when +there’s data in the table? +Have you ever written a **perfect** migration only to merge it and later +find out that someone else merged also merged a migration and your CD is +now broken!? +`pytest-alembic` is meant to (with a little help) solve all these +problems and more. Note, due to a few different factors, there **may** +be some [minimal required +setup](http://pytest-alembic.readthedocs.io/en/latest/setup.html); +however most of it is boilerplate akin to the setup required for alembic +itself. +### Built-in Tests +- **test_single_head_revision** + Assert that there only exists one head revision. + We’re not sure what realistic scenario involves a diverging history to + be desirable. We have only seen it be the result of uncaught merge + conflicts resulting in a diverged history, which lazily breaks during + deployment. +- **test_upgrade** + Assert that the revision history can be run through from base to head. +- **test_model_definitions_match_ddl** + Assert that the state of the migrations matches the state of the + models describing the DDL. + In general, the set of migrations in the history should coalesce into + DDL which is described by the current set of models. Therefore, a call + to `revision --autogenerate` should always generate an empty migration + (e.g. find no difference between your database (i.e. migrations + history) and your models). +- **test_up_down_consistency** + Assert that all downgrades succeed. + While downgrading may not be lossless operation data-wise, there’s a + theory of database migrations that says that the revisions in + existence for a database should be able to go from an entirely blank + schema to the finished product, and back again. +- [Experimental + tests](http://pytest-alembic.readthedocs.io/en/latest/experimental_tests.html) + - all_models_register_on_metadata + Assert that all defined models are imported statically. + Prevents scenarios in which the minimal import of your models in your `env.py` + does not import all extant models, leading alembic to not autogenerate all + your models, or (worse!) suggest the deletion of tables which should still exist. + - downgrade_leaves_no_trace + Assert that there is no difference between the state of the database pre/post downgrade. + In essence this is a much more strict version of `test_up_down_consistency`, + where the state of a MetaData before and after a downgrade are identical as + far as alembic (autogenerate) is concerned. + These tests will need to be enabled manually because their semantics or API are + not yet guaranteed to stay the same. See the linked docs for more details! +Let us know if you have any ideas for more built-in tests which would be +generally useful for most alembic histories! +### Custom Tests +For more information, see the docs for [custom +tests](http://pytest-alembic.readthedocs.io/en/latest/custom_tests.html) +(example below) or [custom static +data](http://pytest-alembic.readthedocs.io/en/latest/custom_data.html) +(to be inserted automatically before a given revision). +Sometimes when writing a particularly gnarly data migration, it helps to +be able to practice a little timely TDD, since there’s always the +potential you’ll trash your actual production data. +With `pytest-alembic`, you can write tests directly, in the same way +that you would normally, through the use of the `alembic_runner` +fixture. +```python +def test_gnarly_migration_xyz123(alembic_engine, alembic_runner): + # Migrate up to, but not including this new migration + alembic_runner.migrate_up_before('xyz123') + # Perform some very specific data setup, because this migration is sooooo complex. + # ... + alembic_engine.execute(table.insert(id=1, name='foo')) + alembic_runner.migrate_up_one() +``` +`alembic_runner` has a number of methods designed to make it convenient +to change the state of your database up, down, and all around. +## Installing +```bash +pip install "pytest-alembic" +``` + +%package help +Summary: Development documents and examples for pytest-alembic +Provides: python3-pytest-alembic-doc +%description help +``` +## The pitch +Have you ever merged a change to your models and you forgot to generate +a migration? +Have you ever written a migration only to realize that it fails when +there’s data in the table? +Have you ever written a **perfect** migration only to merge it and later +find out that someone else merged also merged a migration and your CD is +now broken!? +`pytest-alembic` is meant to (with a little help) solve all these +problems and more. Note, due to a few different factors, there **may** +be some [minimal required +setup](http://pytest-alembic.readthedocs.io/en/latest/setup.html); +however most of it is boilerplate akin to the setup required for alembic +itself. +### Built-in Tests +- **test_single_head_revision** + Assert that there only exists one head revision. + We’re not sure what realistic scenario involves a diverging history to + be desirable. We have only seen it be the result of uncaught merge + conflicts resulting in a diverged history, which lazily breaks during + deployment. +- **test_upgrade** + Assert that the revision history can be run through from base to head. +- **test_model_definitions_match_ddl** + Assert that the state of the migrations matches the state of the + models describing the DDL. + In general, the set of migrations in the history should coalesce into + DDL which is described by the current set of models. Therefore, a call + to `revision --autogenerate` should always generate an empty migration + (e.g. find no difference between your database (i.e. migrations + history) and your models). +- **test_up_down_consistency** + Assert that all downgrades succeed. + While downgrading may not be lossless operation data-wise, there’s a + theory of database migrations that says that the revisions in + existence for a database should be able to go from an entirely blank + schema to the finished product, and back again. +- [Experimental + tests](http://pytest-alembic.readthedocs.io/en/latest/experimental_tests.html) + - all_models_register_on_metadata + Assert that all defined models are imported statically. + Prevents scenarios in which the minimal import of your models in your `env.py` + does not import all extant models, leading alembic to not autogenerate all + your models, or (worse!) suggest the deletion of tables which should still exist. + - downgrade_leaves_no_trace + Assert that there is no difference between the state of the database pre/post downgrade. + In essence this is a much more strict version of `test_up_down_consistency`, + where the state of a MetaData before and after a downgrade are identical as + far as alembic (autogenerate) is concerned. + These tests will need to be enabled manually because their semantics or API are + not yet guaranteed to stay the same. See the linked docs for more details! +Let us know if you have any ideas for more built-in tests which would be +generally useful for most alembic histories! +### Custom Tests +For more information, see the docs for [custom +tests](http://pytest-alembic.readthedocs.io/en/latest/custom_tests.html) +(example below) or [custom static +data](http://pytest-alembic.readthedocs.io/en/latest/custom_data.html) +(to be inserted automatically before a given revision). +Sometimes when writing a particularly gnarly data migration, it helps to +be able to practice a little timely TDD, since there’s always the +potential you’ll trash your actual production data. +With `pytest-alembic`, you can write tests directly, in the same way +that you would normally, through the use of the `alembic_runner` +fixture. +```python +def test_gnarly_migration_xyz123(alembic_engine, alembic_runner): + # Migrate up to, but not including this new migration + alembic_runner.migrate_up_before('xyz123') + # Perform some very specific data setup, because this migration is sooooo complex. + # ... + alembic_engine.execute(table.insert(id=1, name='foo')) + alembic_runner.migrate_up_one() +``` +`alembic_runner` has a number of methods designed to make it convenient +to change the state of your database up, down, and all around. +## Installing +```bash +pip install "pytest-alembic" +``` + +%prep +%autosetup -n pytest-alembic-0.10.1 + +%build +%py3_build + +%install +%py3_install +install -d -m755 %{buildroot}/%{_pkgdocdir} +if [ -d doc ]; then cp -arf doc %{buildroot}/%{_pkgdocdir}; fi +if [ -d docs ]; then cp -arf docs %{buildroot}/%{_pkgdocdir}; fi +if [ -d example ]; then cp -arf example %{buildroot}/%{_pkgdocdir}; fi +if [ -d examples ]; then cp -arf examples %{buildroot}/%{_pkgdocdir}; fi +pushd %{buildroot} +if [ -d usr/lib ]; then + find usr/lib -type f -printf "/%h/%f\n" >> filelist.lst +fi +if [ -d usr/lib64 ]; then + find usr/lib64 -type f -printf "/%h/%f\n" >> filelist.lst +fi +if [ -d usr/bin ]; then + find usr/bin -type f -printf "/%h/%f\n" >> filelist.lst +fi +if [ -d usr/sbin ]; then + find usr/sbin -type f -printf "/%h/%f\n" >> filelist.lst +fi +touch doclist.lst +if [ -d usr/share/man ]; then + find usr/share/man -type f -printf "/%h/%f.gz\n" >> doclist.lst +fi +popd +mv %{buildroot}/filelist.lst . +mv %{buildroot}/doclist.lst . + +%files -n python3-pytest-alembic -f filelist.lst +%dir %{python3_sitelib}/* + +%files help -f doclist.lst +%{_docdir}/* + +%changelog +* Tue Apr 11 2023 Python_Bot <Python_Bot@openeuler.org> - 0.10.1-1 +- Package Spec generated @@ -0,0 +1 @@ +8fbdaedf35010d068f4180e8570d3b00 pytest_alembic-0.10.1.tar.gz |