automatic import of python-pytest-alembic

3 files changed, 317 insertions, 0 deletions

diff --git a/.gitignore b/.gitignore
index e69de29..14973c7 100644
--- a/.gitignore
+++ b/.gitignore
@@ -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
diff --git a/sources b/sources
new file mode 100644
index 0000000..2ead219
--- /dev/null
+++ b/sources
@@ -0,0 +1 @@
+8fbdaedf35010d068f4180e8570d3b00  pytest_alembic-0.10.1.tar.gz