Remove namespace packaging and hardcode elements #4767
Merged
+112
−33
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Namespace packages are constant source of problems for users. The python packaging ecosystem around splitting packages across namespaces is fragile at the best of times and can often leave a you with an environment that isn't recoverable (especially when mixing install methods). There is also a performance hit whenever there is a piece of the namespace we allow external packages to extend since it requires doing a full python path search which can be slow depending on the backing I/O and the number of paths in sys.path for an environment. This commit starts the process of addressing this by removing the arbitrary namespace hook points and hard coding the element namespace maps via a custom import loader at the root of the namespace. This has 2 advantages it removes the use of namespace packages so the fragility and performance impact are fixed since every element will be renamed to use 'qiskit_*' instead of 'qiskit.*', but it also makes it explicit where we extend the namespace. The previous method allowed any package to extend qiskit.* and qiskit.providers.* with whatever they wanted. We'll need to coordinate updating the elements with this merging, because it is a breaking change for each element (although not for end users). A potential follow on is to add a plugin interface for 3rd party providers like what was proposed in Qiskit#1465 so that we can make external providers externally discoverable without needing to add manual hook points moving forward (this was done for backwards compat with the aqt and honeywell provider). Fixes Qiskit#559
mtreinish
added a commit
to mtreinish/aqua
that referenced
this pull request
Jul 21, 2020
Namespace packages are constant source of problems for users. The python packaging ecosystem around splitting packages across namespaces is fragile at the best of times and can often leave a you with an environment that isn't recoverable (especially when mixing install methods). There is also a performance hit whenever there is a piece of the namespace we allow external packages to extend since it requires doing a full python path search which can be slow depending on the backing I/O and the number of paths in sys.path for an environment. This commit addresses the piece from the aer perspective by moving qiskit.aqua to it's own package and namespace 'qiskit_aqua' and each of the application packages (chemistry, finance, optimization, etc.) are subpackages off of 'qiskit_aqua'. This will be coupled with a change in terra that removes the arbitrary namespace hook points and hard coding the element namespace maps via a custom import loader at the root of the namespace. This has 2 advantages it removes the use of namespace packages so the fragility and performance impact are fixed since every element will be renamed to use 'qiskit_*' instead of 'qiskit.*', but it also makes it explicit where we extend the namespace. The previous method allowed any package to extend qiskit.* and qiskit.providers.* with whatever they wanted. This commit will need to be coordinated with the terra change to ensure we don't block development, because while it's not breaking for end users as a coordinated code release piecewise it's a breaking change for each element, including Aqua. Depends-on: Qiskit/qiskit#4767 Fixes Qiskit/qiskit#559
mtreinish
added a commit
to mtreinish/qiskit-ignis
that referenced
this pull request
Jul 21, 2020
Namespace packages are constant source of problems for users. The python packaging ecosystem around splitting packages across namespaces is fragile at the best of times and can often leave a you with an environment that isn't recoverable (especially when mixing install methods). There is also a performance hit whenever there is a piece of the namespace we allow external packages to extend since it requires doing a full python path search which can be slow depending on the backing I/O and the number of paths in sys.path for an environment. This commit addresses the piece from the ignis perspective by moving qiskit.ignis to it's own package and namespace 'qiskit_ignis'. This will be coupled with a change in terra that removes the arbitrary namespace hook points and hard coding the element namespace maps via a custom import loader at the root of the namespace. This has 2 advantages it removes the use of namespace packages so the fragility and performance impact are fixed since every element will be renamed to use 'qiskit_*' instead of 'qiskit.*', but it also makes it explicit where we extend the namespace. The previous method allowed any package to extend qiskit.* and qiskit.providers.* with whatever they wanted. This commit will need to be coordinated with the terra change to ensure we don't block development, because while it's not breaking for end users as a coordinated code release piecewise it's a breaking change for each element, including Ignis. Depends-On: Qiskit/qiskit#4767 Fixes Qiskit/qiskit#559
mtreinish
added a commit
to mtreinish/qiskit-aer
that referenced
this pull request
Jul 21, 2020
Namespace packages are constant source of problems for users. The python packaging ecosystem around splitting packages across namespaces is fragile at the best of times and can often leave a you with an environment that isn't recoverable (especially when mixing install methods). There is also a performance hit whenever there is a piece of the namespace we allow external packages to extend since it requires doing a full python path search which can be slow depending on the backing I/O and the number of paths in sys.path for an environment. This commit addresses the piece from the aer perspective by moving qiskit.providers.aer to it's own package and namespace 'qiskit_aer'. This will be coupled with a change in terra that removes the arbitrary namespace hook points and hard coding the element namespace maps via a custom import loader at the root of the namespace. This has 2 advantages it removes the use of namespace packages so the fragility and performance impact are fixed since every element will be renamed to use 'qiskit_*' instead of 'qiskit.*', but it also makes it explicit where we extend the namespace. The previous method allowed any package to extend qiskit.* and qiskit.providers.* with whatever they wanted. This commit will need to be coordinated with the terra change to ensure we don't block development, because while it's not breaking for end users as a coordinated code release piecewise it's a breaking change for each element, including Aer. Depends-On: Qiskit/qiskit#4767 Fixes Qiskit/qiskit#559
mtreinish
added a commit
to mtreinish/qiskit-ibmq-provider
that referenced
this pull request
Jul 21, 2020
Namespace packages are constant source of problems for users. The python packaging ecosystem around splitting packages across namespaces is fragile at the best of times and can often leave a you with an environment that isn't recoverable (especially when mixing install methods). There is also a performance hit whenever there is a piece of the namespace we allow external packages to extend since it requires doing a full python path search which can be slow depending on the backing I/O and the number of paths in sys.path for an environment. This commit addresses the piece from the aer perspective by moving qiskit.providers.ibmq to it's own package and namespace 'qiskit_ibmq_provider'. This will be coupled with a change in terra that removes the arbitrary namespace hook points and hard coding the element namespace maps via a custom import loader at the root of the namespace. This has 2 advantages it removes the use of namespace packages so the fragility and performance impact are fixed since every element will be renamed to use 'qiskit_*' instead of 'qiskit.*', but it also makes it explicit where we extend the namespace. The previous method allowed any package to extend qiskit.* and qiskit.providers.* with whatever they wanted. This commit will need to be coordinated with the terra change to ensure we don't block development, because while it's not breaking for end users as a coordinated code release, piecewise it's a breaking change for each element, including the IBMQ provider. Depends-On: Qiskit/qiskit#4767 Fixes Qiskit/qiskit#559
mtreinish
added a commit
to mtreinish/qiskit-core
that referenced
this pull request
Aug 13, 2020
This commit drops support for running with python 3.5. It marks the minimum supported version of the package as python 3.6, removes python 3.5 package pins, removes the 3.5 CI jobs, and removes the warning on python 3.5. Looking at the PyPI stats since the deprecation period started the number of users on Python 3.5 has diminished significantly, but not disappeared. There were 783 downloads with pip from pypi out of total of 25782 total pip downloads in the last 30 days. Compared to the roughly 10% figure when we deprecated Python 3.5. Merging this means we can not release until after the documented EoL date for Python 3.5 support of September 13. This shouldn't be a problem because with Qiskit#4767 we will need to coordinate the release of all the qiskit elements and are planning to do that after 09/13/2020. It's worth noting that we should start planning to deprecate python 3.6 support sooner rather than later it goes EoL upstream at the end of next year [1] and some of our other upstream dependencies (mainly numpy et al) are going to remove support before the upstream Python EoL date [2]. [1] https://devguide.python.org/#branchstatus [2] https://numpy.org/neps/nep-0029-deprecation_policy.html
mtreinish
added a commit
to mtreinish/aqua
that referenced
this pull request
Aug 31, 2020
Namespace packages are constant source of problems for users. The python packaging ecosystem around splitting packages across namespaces is fragile at the best of times and can often leave a you with an environment that isn't recoverable (especially when mixing install methods). There is also a performance hit whenever there is a piece of the namespace we allow external packages to extend since it requires doing a full python path search which can be slow depending on the backing I/O and the number of paths in sys.path for an environment. This commit addresses the piece from the aer perspective by moving qiskit.aqua to it's own package and namespace 'qiskit_aqua' and each of the application packages (chemistry, finance, optimization, etc.) are subpackages off of 'qiskit_aqua'. This will be coupled with a change in terra that removes the arbitrary namespace hook points and hard coding the element namespace maps via a custom import loader at the root of the namespace. This has 2 advantages it removes the use of namespace packages so the fragility and performance impact are fixed since every element will be renamed to use 'qiskit_*' instead of 'qiskit.*', but it also makes it explicit where we extend the namespace. The previous method allowed any package to extend qiskit.* and qiskit.providers.* with whatever they wanted. This commit will need to be coordinated with the terra change to ensure we don't block development, because while it's not breaking for end users as a coordinated code release piecewise it's a breaking change for each element, including Aqua. Depends-on: Qiskit/qiskit#4767 Fixes Qiskit/qiskit#559
mtreinish
added a commit
to mtreinish/qiskit-ignis
that referenced
this pull request
Aug 31, 2020
Namespace packages are constant source of problems for users. The python packaging ecosystem around splitting packages across namespaces is fragile at the best of times and can often leave a you with an environment that isn't recoverable (especially when mixing install methods). There is also a performance hit whenever there is a piece of the namespace we allow external packages to extend since it requires doing a full python path search which can be slow depending on the backing I/O and the number of paths in sys.path for an environment. This commit addresses the piece from the ignis perspective by moving qiskit.ignis to it's own package and namespace 'qiskit_ignis'. This will be coupled with a change in terra that removes the arbitrary namespace hook points and hard coding the element namespace maps via a custom import loader at the root of the namespace. This has 2 advantages it removes the use of namespace packages so the fragility and performance impact are fixed since every element will be renamed to use 'qiskit_*' instead of 'qiskit.*', but it also makes it explicit where we extend the namespace. The previous method allowed any package to extend qiskit.* and qiskit.providers.* with whatever they wanted. This commit will need to be coordinated with the terra change to ensure we don't block development, because while it's not breaking for end users as a coordinated code release piecewise it's a breaking change for each element, including Ignis. Depends-On: Qiskit/qiskit#4767 Fixes Qiskit/qiskit#559
mtreinish
added a commit
to mtreinish/qiskit-aer
that referenced
this pull request
Aug 31, 2020
Namespace packages are constant source of problems for users. The python packaging ecosystem around splitting packages across namespaces is fragile at the best of times and can often leave a you with an environment that isn't recoverable (especially when mixing install methods). There is also a performance hit whenever there is a piece of the namespace we allow external packages to extend since it requires doing a full python path search which can be slow depending on the backing I/O and the number of paths in sys.path for an environment. This commit addresses the piece from the aer perspective by moving qiskit.providers.aer to it's own package and namespace 'qiskit_aer'. This will be coupled with a change in terra that removes the arbitrary namespace hook points and hard coding the element namespace maps via a custom import loader at the root of the namespace. This has 2 advantages it removes the use of namespace packages so the fragility and performance impact are fixed since every element will be renamed to use 'qiskit_*' instead of 'qiskit.*', but it also makes it explicit where we extend the namespace. The previous method allowed any package to extend qiskit.* and qiskit.providers.* with whatever they wanted. This commit will need to be coordinated with the terra change to ensure we don't block development, because while it's not breaking for end users as a coordinated code release piecewise it's a breaking change for each element, including Aer. Depends-On: Qiskit/qiskit#4767 Fixes Qiskit/qiskit#559
mtreinish
added a commit
to mtreinish/qiskit-ibmq-provider
that referenced
this pull request
Aug 31, 2020
Namespace packages are constant source of problems for users. The python packaging ecosystem around splitting packages across namespaces is fragile at the best of times and can often leave a you with an environment that isn't recoverable (especially when mixing install methods). There is also a performance hit whenever there is a piece of the namespace we allow external packages to extend since it requires doing a full python path search which can be slow depending on the backing I/O and the number of paths in sys.path for an environment. This commit addresses the piece from the aer perspective by moving qiskit.providers.ibmq to it's own package and namespace 'qiskit_ibmq_provider'. This will be coupled with a change in terra that removes the arbitrary namespace hook points and hard coding the element namespace maps via a custom import loader at the root of the namespace. This has 2 advantages it removes the use of namespace packages so the fragility and performance impact are fixed since every element will be renamed to use 'qiskit_*' instead of 'qiskit.*', but it also makes it explicit where we extend the namespace. The previous method allowed any package to extend qiskit.* and qiskit.providers.* with whatever they wanted. This commit will need to be coordinated with the terra change to ensure we don't block development, because while it's not breaking for end users as a coordinated code release, piecewise it's a breaking change for each element, including the IBMQ provider. Depends-On: Qiskit/qiskit#4767 Fixes Qiskit/qiskit#559
mtreinish
added a commit
to mtreinish/qiskit-aer
that referenced
this pull request
Sep 1, 2020
This commit drops support for running with python 3.5. It marks the minimum supported version of the package as python 3.6, removes python 3.5 package pins, removes the 3.5 CI jobs, and removes the warning on python 3.5. Looking at the PyPI stats since the deprecation period started the number of users on Python 3.5 has diminished significantly, but not disappeared. There were 359 downloads with pip from pypi out of total of 18,980 total pip downloads in the last 30 days. Compared to the roughly 10% figure when we deprecated Python 3.5. Merging this means we can not release until after the documented EoL date for Python 3.5 support of September 13. This shouldn't be a problem because with Qiskit/qiskit#4767 we will need to coordinate the release of all the qiskit elements and are planning to do that after 09/13/2020. It's worth noting that we should start planning to deprecate python 3.6 support sooner rather than later it goes EoL upstream at the end of next year [1] and some of our other upstream dependencies (mainly numpy et al) are going to remove support before the upstream Python EoL date [2]. [1] https://devguide.python.org/#branchstatus [2] https://numpy.org/neps/nep-0029-deprecation_policy.html
mtreinish
added a commit
to mtreinish/qiskit-ignis
that referenced
this pull request
Sep 1, 2020
This commit drops support for running with python 3.5. It marks the minimum supported version of the package as python 3.6, removes python 3.5 package pins, removes the 3.5 CI jobs, and removes the warning on python 3.5. Looking at the PyPI stats since the deprecation period started the number of users on Python 3.5 has diminished significantly, but not disappeared. There were 101 downloads with pip from pypi out of total of 15,746 total pip downloads in the last 30 days. Compared to the roughly 10% figure when we deprecated Python 3.5. Merging this means we can not release until after the documented EoL date for Python 3.5 support of September 13. This shouldn't be a problem because with Qiskit/qiskit#4767 we will need to coordinate the release of all the qiskit elements and are planning to do that after 09/13/2020. It's worth noting that we should start planning to deprecate python 3.6 support sooner rather than later it goes EoL upstream at the end of next year [1] and some of our other upstream dependencies (mainly numpy et al) are going to remove support before the upstream Python EoL date [2]. [1] https://devguide.python.org/#branchstatus [2] https://numpy.org/neps/nep-0029-deprecation_policy.html
kdk
added a commit
that referenced
this pull request
Sep 1, 2020
This commit drops support for running with python 3.5. It marks the minimum supported version of the package as python 3.6, removes python 3.5 package pins, removes the 3.5 CI jobs, and removes the warning on python 3.5. Looking at the PyPI stats since the deprecation period started the number of users on Python 3.5 has diminished significantly, but not disappeared. There were 783 downloads with pip from pypi out of total of 25782 total pip downloads in the last 30 days. Compared to the roughly 10% figure when we deprecated Python 3.5. Merging this means we can not release until after the documented EoL date for Python 3.5 support of September 13. This shouldn't be a problem because with #4767 we will need to coordinate the release of all the qiskit elements and are planning to do that after 09/13/2020. It's worth noting that we should start planning to deprecate python 3.6 support sooner rather than later it goes EoL upstream at the end of next year [1] and some of our other upstream dependencies (mainly numpy et al) are going to remove support before the upstream Python EoL date [2]. [1] https://devguide.python.org/#branchstatus [2] https://numpy.org/neps/nep-0029-deprecation_policy.html Co-authored-by: Kevin Krsulich <kevin.krsulich@ibm.com>
mtreinish
added a commit
to mtreinish/qiskit-ibmq-provider
that referenced
this pull request
Sep 1, 2020
This commit drops support for running with python 3.5. It marks the minimum supported version of the package as python 3.6, removes python 3.5 package pins, removes the 3.5 CI jobs, and removes the warning on python 3.5. Looking at the PyPI stats since the deprecation period started the number of users on Python 3.5 has diminished significantly, but not disappeared. There were 90 downloads with pip from pypi out of total of 16,615 total pip downloads in the last 30 days. Compared to the roughly 10% figure when we deprecated Python 3.5. Merging this means we can not release until after the documented EoL date for Python 3.5 support of September 13. This shouldn't be a problem because with Qiskit/qiskit#4767 we will need to coordinate the release of all the qiskit elements and are planning to do that after 09/13/2020. It's worth noting that we should start planning to deprecate python 3.6 support sooner rather than later it goes EoL upstream at the end of next year [1] and some of our other upstream dependencies (mainly numpy et al) are going to remove support before the upstream Python EoL date [2]. [1] https://devguide.python.org/#branchstatus [2] https://numpy.org/neps/nep-0029-deprecation_policy.html
mtreinish
added a commit
to mtreinish/aqua
that referenced
this pull request
Sep 1, 2020
This commit drops support for running with python 3.5. It marks the minimum supported version of the package as python 3.6, removes python 3.5 package pins, removes the 3.5 CI jobs, and removes the warning on python 3.5. Looking at the PyPI stats since the deprecation period started the number of users on Python 3.5 has diminished significantly, but not disappeared. There were 98 downloads with pip from pypi out of total of 15,357 total pip downloads in the last 30 days. Compared to the roughly 10% figure when we deprecated Python 3.5. Merging this means we can not release until after the documented EoL date for Python 3.5 support of September 13. This shouldn't be a problem because with Qiskit/qiskit#4767 we will need to coordinate the release of all the qiskit elements and are planning to do that after 09/13/2020. It's worth noting that we should start planning to deprecate python 3.6 support sooner rather than later it goes EoL upstream at the end of next year [1] and some of our other upstream dependencies (mainly numpy et al) are going to remove support before the upstream Python EoL date [2]. [1] https://devguide.python.org/#branchstatus [2] https://numpy.org/neps/nep-0029-deprecation_policy.html
chriseclectic
pushed a commit
to qiskit-community/qiskit-ignis
that referenced
this pull request
Sep 1, 2020
This commit drops support for running with python 3.5. It marks the minimum supported version of the package as python 3.6, removes python 3.5 package pins, removes the 3.5 CI jobs, and removes the warning on python 3.5. Looking at the PyPI stats since the deprecation period started the number of users on Python 3.5 has diminished significantly, but not disappeared. There were 101 downloads with pip from pypi out of total of 15,746 total pip downloads in the last 30 days. Compared to the roughly 10% figure when we deprecated Python 3.5. Merging this means we can not release until after the documented EoL date for Python 3.5 support of September 13. This shouldn't be a problem because with Qiskit/qiskit#4767 we will need to coordinate the release of all the qiskit elements and are planning to do that after 09/13/2020. It's worth noting that we should start planning to deprecate python 3.6 support sooner rather than later it goes EoL upstream at the end of next year [1] and some of our other upstream dependencies (mainly numpy et al) are going to remove support before the upstream Python EoL date [2]. [1] https://devguide.python.org/#branchstatus [2] https://numpy.org/neps/nep-0029-deprecation_policy.html
manoelmarques
pushed a commit
to qiskit-community/qiskit-aqua
that referenced
this pull request
Sep 1, 2020
* Drop support for Python 3.5 This commit drops support for running with python 3.5. It marks the minimum supported version of the package as python 3.6, removes python 3.5 package pins, removes the 3.5 CI jobs, and removes the warning on python 3.5. Looking at the PyPI stats since the deprecation period started the number of users on Python 3.5 has diminished significantly, but not disappeared. There were 98 downloads with pip from pypi out of total of 15,357 total pip downloads in the last 30 days. Compared to the roughly 10% figure when we deprecated Python 3.5. Merging this means we can not release until after the documented EoL date for Python 3.5 support of September 13. This shouldn't be a problem because with Qiskit/qiskit#4767 we will need to coordinate the release of all the qiskit elements and are planning to do that after 09/13/2020. It's worth noting that we should start planning to deprecate python 3.6 support sooner rather than later it goes EoL upstream at the end of next year [1] and some of our other upstream dependencies (mainly numpy et al) are going to remove support before the upstream Python EoL date [2]. [1] https://devguide.python.org/#branchstatus [2] https://numpy.org/neps/nep-0029-deprecation_policy.html * Bump python version for mypy job
chriseclectic
pushed a commit
to Qiskit/qiskit-aer
that referenced
this pull request
Sep 1, 2020
This commit drops support for running with python 3.5. It marks the minimum supported version of the package as python 3.6, removes python 3.5 package pins, removes the 3.5 CI jobs, and removes the warning on python 3.5. Looking at the PyPI stats since the deprecation period started the number of users on Python 3.5 has diminished significantly, but not disappeared. There were 359 downloads with pip from pypi out of total of 18,980 total pip downloads in the last 30 days. Compared to the roughly 10% figure when we deprecated Python 3.5. Merging this means we can not release until after the documented EoL date for Python 3.5 support of September 13. This shouldn't be a problem because with Qiskit/qiskit#4767 we will need to coordinate the release of all the qiskit elements and are planning to do that after 09/13/2020. It's worth noting that we should start planning to deprecate python 3.6 support sooner rather than later it goes EoL upstream at the end of next year [1] and some of our other upstream dependencies (mainly numpy et al) are going to remove support before the upstream Python EoL date [2]. [1] https://devguide.python.org/#branchstatus [2] https://numpy.org/neps/nep-0029-deprecation_policy.html
ewinston
pushed a commit
to ewinston/qiskit
that referenced
this pull request
Sep 9, 2020
This commit drops support for running with python 3.5. It marks the minimum supported version of the package as python 3.6, removes python 3.5 package pins, removes the 3.5 CI jobs, and removes the warning on python 3.5. Looking at the PyPI stats since the deprecation period started the number of users on Python 3.5 has diminished significantly, but not disappeared. There were 783 downloads with pip from pypi out of total of 25782 total pip downloads in the last 30 days. Compared to the roughly 10% figure when we deprecated Python 3.5. Merging this means we can not release until after the documented EoL date for Python 3.5 support of September 13. This shouldn't be a problem because with Qiskit#4767 we will need to coordinate the release of all the qiskit elements and are planning to do that after 09/13/2020. It's worth noting that we should start planning to deprecate python 3.6 support sooner rather than later it goes EoL upstream at the end of next year [1] and some of our other upstream dependencies (mainly numpy et al) are going to remove support before the upstream Python EoL date [2]. [1] https://devguide.python.org/#branchstatus [2] https://numpy.org/neps/nep-0029-deprecation_policy.html Co-authored-by: Kevin Krsulich <kevin.krsulich@ibm.com>
pbark
pushed a commit
to pbark/qiskit-aqua
that referenced
this pull request
Sep 16, 2020
* Drop support for Python 3.5 This commit drops support for running with python 3.5. It marks the minimum supported version of the package as python 3.6, removes python 3.5 package pins, removes the 3.5 CI jobs, and removes the warning on python 3.5. Looking at the PyPI stats since the deprecation period started the number of users on Python 3.5 has diminished significantly, but not disappeared. There were 98 downloads with pip from pypi out of total of 15,357 total pip downloads in the last 30 days. Compared to the roughly 10% figure when we deprecated Python 3.5. Merging this means we can not release until after the documented EoL date for Python 3.5 support of September 13. This shouldn't be a problem because with Qiskit/qiskit#4767 we will need to coordinate the release of all the qiskit elements and are planning to do that after 09/13/2020. It's worth noting that we should start planning to deprecate python 3.6 support sooner rather than later it goes EoL upstream at the end of next year [1] and some of our other upstream dependencies (mainly numpy et al) are going to remove support before the upstream Python EoL date [2]. [1] https://devguide.python.org/#branchstatus [2] https://numpy.org/neps/nep-0029-deprecation_policy.html * Bump python version for mypy job
jyu00
added a commit
to Qiskit/qiskit-ibmq-provider
that referenced
this pull request
Sep 16, 2020
* Drop support for Python 3.5 This commit drops support for running with python 3.5. It marks the minimum supported version of the package as python 3.6, removes python 3.5 package pins, removes the 3.5 CI jobs, and removes the warning on python 3.5. Looking at the PyPI stats since the deprecation period started the number of users on Python 3.5 has diminished significantly, but not disappeared. There were 90 downloads with pip from pypi out of total of 16,615 total pip downloads in the last 30 days. Compared to the roughly 10% figure when we deprecated Python 3.5. Merging this means we can not release until after the documented EoL date for Python 3.5 support of September 13. This shouldn't be a problem because with Qiskit/qiskit#4767 we will need to coordinate the release of all the qiskit elements and are planning to do that after 09/13/2020. It's worth noting that we should start planning to deprecate python 3.6 support sooner rather than later it goes EoL upstream at the end of next year [1] and some of our other upstream dependencies (mainly numpy et al) are going to remove support before the upstream Python EoL date [2]. [1] https://devguide.python.org/#branchstatus [2] https://numpy.org/neps/nep-0029-deprecation_policy.html * Add release notes * Update version in release note Co-authored-by: Jessie Yu <jessieyu@us.ibm.com>
mtreinish
added a commit
to mtreinish/qiskit-core
that referenced
this pull request
Sep 18, 2020
Namespace packages are constant source of problems for users. The python packaging ecosystem around splitting packages across namespaces is fragile at the best of times and can often leave a you with an environment that isn't recoverable (especially when mixing install methods). There is also a performance hit whenever there is a piece of the namespace we allow external packages to extend since it requires doing a full python path search which can be slow depending on the backing I/O and the number of paths in sys.path for an environment. This commit starts the process of addressing this by removing the arbitrary namespace hook points and hard coding the element namespace maps via a custom import loader at the root of the namespace. This has 2 advantages it removes the use of namespace packages so the fragility and performance impact are fixed since every element will be renamed to use 'qiskit_' instead of 'qiskit.', but it also makes it explicit where we extend the namespace. The previous method allowed any package to extend qiskit.* and qiskit.providers.* with whatever they wanted. We'll need to coordinate updating the elements with this merging, because it is a breaking change for each element (although not for end users). A potential follow on is to add a plugin interface for 3rd party providers like what was proposed in Qiskit#1465 so that we can make external providers externally discoverable without needing to add manual hook points moving forward (this was done for backwards compat with the aqt and honeywell provider). This is a second attempt at removing namespace packaging. The first attempt in PR Qiskit#4767 was merged and had to be reverted because there were some circular import error issues that needed to be resolved. Since having this in terra blocks CI for all the qiskit elements a revert was necessary to unblock developement for the entire project while those were resolved.
mtreinish
added a commit
to mtreinish/qiskit-aer
that referenced
this pull request
Sep 18, 2020
Namespace packages are constant source of problems for users. The python packaging ecosystem around splitting packages across namespaces is fragile at the best of times and can often leave a you with an environment that isn't recoverable (especially when mixing install methods). There is also a performance hit whenever there is a piece of the namespace we allow external packages to extend since it requires doing a full python path search which can be slow depending on the backing I/O and the number of paths in sys.path for an environment. This commit addresses the piece from the aer perspective by moving qiskit.providers.aer to it's own package and namespace 'qiskit_aer'. This will be coupled with a change in terra that removes the arbitrary namespace hook points and hard coding the element namespace maps via a custom import loader at the root of the namespace. This has 2 advantages it removes the use of namespace packages so the fragility and performance impact are fixed since every element will be renamed to use 'qiskit_*' instead of 'qiskit.*', but it also makes it explicit where we extend the namespace. The previous method allowed any package to extend qiskit.* and qiskit.providers.* with whatever they wanted. This commit will need to be coordinated with the terra change to ensure we don't block development, because while it's not breaking for end users as a coordinated code release piecewise it's a breaking change for each element, including Aer. Depends-On: Qiskit/qiskit#4767 Fixes Qiskit/qiskit#559
mergify bot
added a commit
that referenced
this pull request
Sep 24, 2020
* basicaer handling of global_phase. Also, adapted some transpiler passes to preserve global phase in dag. * catch non-float global_phase * update state vector simulator * linting * blank line needed * update Decompose pass for global phase * update transpiler passes which create new dagcircuits. This preserves global phase in newly created dagcircuit. * Drop support for python 3.5 (#4926) This commit drops support for running with python 3.5. It marks the minimum supported version of the package as python 3.6, removes python 3.5 package pins, removes the 3.5 CI jobs, and removes the warning on python 3.5. Looking at the PyPI stats since the deprecation period started the number of users on Python 3.5 has diminished significantly, but not disappeared. There were 783 downloads with pip from pypi out of total of 25782 total pip downloads in the last 30 days. Compared to the roughly 10% figure when we deprecated Python 3.5. Merging this means we can not release until after the documented EoL date for Python 3.5 support of September 13. This shouldn't be a problem because with #4767 we will need to coordinate the release of all the qiskit elements and are planning to do that after 09/13/2020. It's worth noting that we should start planning to deprecate python 3.6 support sooner rather than later it goes EoL upstream at the end of next year [1] and some of our other upstream dependencies (mainly numpy et al) are going to remove support before the upstream Python EoL date [2]. [1] https://devguide.python.org/#branchstatus [2] https://numpy.org/neps/nep-0029-deprecation_policy.html Co-authored-by: Kevin Krsulich <kevin.krsulich@ibm.com> * Explicity set encoding of release notes via reno config (#5013) The recent reno release 3.2.0 included a new feature [1] for setting the character encoding that reno uses for all it's files. [2] This commit sets this option in the reno config file to make the release note files explicitly utf8. This is important (especially for windows users) because we have literal inlines of the text drawer in some release notes which use utf8 characters. This should avoid issues for users who's system encoding is not compatible with the text drawer output in the release notes. [1] https://opendev.org/openstack/reno/commit/984bcba17e4e0b46763f42015d09680e5c5d5a04 [2] https://docs.openstack.org/reno/latest/user/usage.html#configuring-reno * Fix parameterized Gate.definition to have valid ParameterTable. (#4945) Co-authored-by: mergify[bot] <37929162+mergify[bot]@users.noreply.github.com> * Allow ParameterExpressions to be cast to ints (#5001) - Resolves #4978 Co-authored-by: Kevin Krsulich <kevin.krsulich@ibm.com> * Add tutorials job to CI (#4907) * Add tutorials job to CI This commit adds a new job to run the qiskit tutorials in CI. The tutorials are used as a form of upgrade testing to ensure that for key examples Qiskit as a whole is N and N+1 releases. This caused friction during the qiskit 0.20.0 release because the tutorials were never updated to stop using deprecated code (or in the case of other elements by merging backwards incompatible changes). To ensure there aren't any surprises at the last minute when we run the tutorials with a proposed new metapackage this commit adds a job to CI to ensure that they always run with terra changes. It means for PRs that change an api (after a deprecation cycle) the tutorial will need to be updated first. This will ensure that users will have an upgrade path because CI in qiskit/qiskit-tutorials runs with the metapackage. * Install pandoc in tutorials job * Remove aqua tutorials from ci job for run time * Fix rm path and speed up tutorials clone * Try pinning matplotlib * Try fixing archive path * Add back aqua tutorials Co-authored-by: Luciano Bello <luciano.bello@ibm.com> Co-authored-by: Kevin Krsulich <kevin.krsulich@ibm.com> * Fix/5015 QuantumCircuit __eq__ should always return a Bool (#5016) * Check if circuit is an instance of QuantumObject before comparing it Added a few tests * Fixed lint error Co-authored-by: Kevin Krsulich <kevin.krsulich@ibm.com> Co-authored-by: mergify[bot] <37929162+mergify[bot]@users.noreply.github.com> * fixed issue 4936 by updating the docstring (#5014) Co-authored-by: Luciano Bello <luciano.bello@ibm.com> Co-authored-by: mergify[bot] <37929162+mergify[bot]@users.noreply.github.com> * fix bux in optimize_1q_gates * minor linting * fix test Co-authored-by: Matthew Treinish <mtreinish@kortar.org> Co-authored-by: Kevin Krsulich <kevin.krsulich@ibm.com> Co-authored-by: mergify[bot] <37929162+mergify[bot]@users.noreply.github.com> Co-authored-by: Andrew Meyer <andrewm1100@gmail.com> Co-authored-by: Luciano Bello <luciano.bello@ibm.com> Co-authored-by: Raul Otaolea <raul.otaolea@gmail.com> Co-authored-by: Tanya Garg <62295887+tgag17@users.noreply.github.com>
jyu00
added a commit
to jyu00/qiskit-ibmq-provider
that referenced
this pull request
Oct 5, 2020
* Drop support for Python 3.5 This commit drops support for running with python 3.5. It marks the minimum supported version of the package as python 3.6, removes python 3.5 package pins, removes the 3.5 CI jobs, and removes the warning on python 3.5. Looking at the PyPI stats since the deprecation period started the number of users on Python 3.5 has diminished significantly, but not disappeared. There were 90 downloads with pip from pypi out of total of 16,615 total pip downloads in the last 30 days. Compared to the roughly 10% figure when we deprecated Python 3.5. Merging this means we can not release until after the documented EoL date for Python 3.5 support of September 13. This shouldn't be a problem because with Qiskit/qiskit#4767 we will need to coordinate the release of all the qiskit elements and are planning to do that after 09/13/2020. It's worth noting that we should start planning to deprecate python 3.6 support sooner rather than later it goes EoL upstream at the end of next year [1] and some of our other upstream dependencies (mainly numpy et al) are going to remove support before the upstream Python EoL date [2]. [1] https://devguide.python.org/#branchstatus [2] https://numpy.org/neps/nep-0029-deprecation_policy.html * Add release notes * Update version in release note Co-authored-by: Jessie Yu <jessieyu@us.ibm.com>
mtreinish
added a commit
to mtreinish/qiskit-aer
that referenced
this pull request
Oct 8, 2020
Namespace packages are constant source of problems for users. The python packaging ecosystem around splitting packages across namespaces is fragile at the best of times and can often leave a you with an environment that isn't recoverable (especially when mixing install methods). There is also a performance hit whenever there is a piece of the namespace we allow external packages to extend since it requires doing a full python path search which can be slow depending on the backing I/O and the number of paths in sys.path for an environment. This commit addresses the piece from the aer perspective by moving qiskit.providers.aer to it's own package and namespace 'qiskit_aer'. This will be coupled with a change in terra that removes the arbitrary namespace hook points and hard coding the element namespace maps via a custom import loader at the root of the namespace. This has 2 advantages it removes the use of namespace packages so the fragility and performance impact are fixed since every element will be renamed to use 'qiskit_*' instead of 'qiskit.*', but it also makes it explicit where we extend the namespace. The previous method allowed any package to extend qiskit.* and qiskit.providers.* with whatever they wanted. This commit will need to be coordinated with the terra change to ensure we don't block development, because while it's not breaking for end users as a coordinated code release piecewise it's a breaking change for each element, including Aer. Depends-On: Qiskit/qiskit#4767 Fixes Qiskit/qiskit#559
mtreinish
added a commit
to mtreinish/qiskit-core
that referenced
this pull request
Jan 13, 2021
This commit migrates the qiskit.Aer and qiskit.IBMQ module attributes to be lazy loading instances of lazy loading wrapper classes. The intent here is to avoid importing from qiskit-aer or qiskit-ibmq-provider from qiskit-terra, while this is safe while the packages share a shared namespace we've been actively working to remove the use of namespace packaging (see Qiskit#5089, Qiskit#4767, and Qiskit#559) and the circular dependency caused by re-exporting these attributes is blocking progress on this. By using a lazy loading wrapper class we avoid an import type circular dependency and opportunistically use qiskit-aer and/or qiskit-ibmq-provider at runtime only if they're present after everything is imported. This also may have some benefit for the overall import performance of qiskit (being tracked in Qiskit#5100) as it removes qiskit-aer and qiskit-ibmq-provider from the import path unless they're being used. Although the presence of qiskit.__qiskit_version__ might prevent any performance improvements as it still imports all the elements to get version information (and will be tackled in a separate PR). Fixes Qiskit#5532
mtreinish
added a commit
to mtreinish/qiskit-core
that referenced
this pull request
Jan 13, 2021
This commit migrates the qiskit.Aer and qiskit.IBMQ module attributes to be lazy loading instances of lazy loading wrapper classes. The intent here is to avoid importing from qiskit-aer or qiskit-ibmq-provider from qiskit-terra, while this is safe while the packages share a shared namespace we've been actively working to remove the use of namespace packaging (see Qiskit#5089, Qiskit#4767, and Qiskit#559) and the circular dependency caused by re-exporting these attributes is blocking progress on this. By using a lazy loading wrapper class we avoid an import type circular dependency and opportunistically use qiskit-aer and/or qiskit-ibmq-provider at runtime only if they're present after everything is imported. This also may have some benefit for the overall import performance of qiskit (being tracked in Qiskit#5100) as it removes qiskit-aer and qiskit-ibmq-provider from the import path unless they're being used. Although the presence of qiskit.__qiskit_version__ might prevent any performance improvements as it still imports all the elements to get version information (and will be tackled in a separate PR). Fixes Qiskit#5532
mergify bot
pushed a commit
that referenced
this pull request
Feb 5, 2021
* Wrap qiskit.Aer and qiskit.IBMQ with lazy loading object This commit migrates the qiskit.Aer and qiskit.IBMQ module attributes to be lazy loading instances of lazy loading wrapper classes. The intent here is to avoid importing from qiskit-aer or qiskit-ibmq-provider from qiskit-terra, while this is safe while the packages share a shared namespace we've been actively working to remove the use of namespace packaging (see #5089, #4767, and #559) and the circular dependency caused by re-exporting these attributes is blocking progress on this. By using a lazy loading wrapper class we avoid an import type circular dependency and opportunistically use qiskit-aer and/or qiskit-ibmq-provider at runtime only if they're present after everything is imported. This also may have some benefit for the overall import performance of qiskit (being tracked in #5100) as it removes qiskit-aer and qiskit-ibmq-provider from the import path unless they're being used. Although the presence of qiskit.__qiskit_version__ might prevent any performance improvements as it still imports all the elements to get version information (and will be tackled in a separate PR). Fixes #5532 * Fix lint * Fix test lint * DNM: test with ignis patch * Revert "DNM: test with ignis patch" This reverts commit ac9611c. * Use ignis from source for tutorial job * Update release note to be more clear
mergify bot
added a commit
that referenced
this pull request
Jun 22, 2022
* Remove namespace packaging and hardcode elements (attempt 2) Namespace packages are constant source of problems for users. The python packaging ecosystem around splitting packages across namespaces is fragile at the best of times and can often leave a you with an environment that isn't recoverable (especially when mixing install methods). There is also a performance hit whenever there is a piece of the namespace we allow external packages to extend since it requires doing a full python path search which can be slow depending on the backing I/O and the number of paths in sys.path for an environment. This commit starts the process of addressing this by removing the arbitrary namespace hook points and hard coding the element namespace maps via a custom import loader at the root of the namespace. This has 2 advantages it removes the use of namespace packages so the fragility and performance impact are fixed since every element will be renamed to use 'qiskit_' instead of 'qiskit.', but it also makes it explicit where we extend the namespace. The previous method allowed any package to extend qiskit.* and qiskit.providers.* with whatever they wanted. We'll need to coordinate updating the elements with this merging, because it is a breaking change for each element (although not for end users). A potential follow on is to add a plugin interface for 3rd party providers like what was proposed in #1465 so that we can make external providers externally discoverable without needing to add manual hook points moving forward (this was done for backwards compat with the aqt and honeywell provider). This is a second attempt at removing namespace packaging. The first attempt in PR #4767 was merged and had to be reverted because there were some circular import error issues that needed to be resolved. Since having this in terra blocks CI for all the qiskit elements a revert was necessary to unblock developement for the entire project while those were resolved. * Try using new aer path for qiskit.Aer alias * Try moving Aer and IBMQ alias to the end * Fix typo * Fix circular import issue * Fix typos * Run black * Remove file encoding * Adjust init with import re-direct * Make qiskit_aer a opportunistic load To ensure that someone with an old version of Aer installed can still access it via the old namespace this changes the meta finder logic to first try qiskit_aer, if it's importable then we build the redirect path first and use that for the legacy qiskit.providers.aer path. If it's not then we just return None and fall back to the other finders in sys.meta_path. To support this the pkgutil hook is added back to qiskit.providers to add the namespace hook for old version of aer using namespace packagingm although not strictly necessary because the implicit support for namespace packages will still likely work we can remove it at a later date. * Deprecate qiskit.Aer entrypoint * Fix lint * Remove unnecessary noqa comments * Revert version.py change and use old aer import for now * Fix typo * Add back pkgutil extension to root init * Make redirect hook more generic * Add comments explaining the various hooks * Make qiskit.Aer a pending deprecation instead of a deprecation * Restrict namespace redirect error to ModuleNotFoundError * Apply suggestions from code review Co-authored-by: Jake Lishman <jake@binhbar.com> Co-authored-by: Jake Lishman <jake@binhbar.com> Co-authored-by: mergify[bot] <37929162+mergify[bot]@users.noreply.github.com>
ElePT
pushed a commit
to ElePT/qiskit
that referenced
this pull request
Jun 27, 2023
* Wrap qiskit.Aer and qiskit.IBMQ with lazy loading object This commit migrates the qiskit.Aer and qiskit.IBMQ module attributes to be lazy loading instances of lazy loading wrapper classes. The intent here is to avoid importing from qiskit-aer or qiskit-ibmq-provider from qiskit-terra, while this is safe while the packages share a shared namespace we've been actively working to remove the use of namespace packaging (see Qiskit#5089, Qiskit#4767, and Qiskit#559) and the circular dependency caused by re-exporting these attributes is blocking progress on this. By using a lazy loading wrapper class we avoid an import type circular dependency and opportunistically use qiskit-aer and/or qiskit-ibmq-provider at runtime only if they're present after everything is imported. This also may have some benefit for the overall import performance of qiskit (being tracked in Qiskit#5100) as it removes qiskit-aer and qiskit-ibmq-provider from the import path unless they're being used. Although the presence of qiskit.__qiskit_version__ might prevent any performance improvements as it still imports all the elements to get version information (and will be tackled in a separate PR). Fixes Qiskit#5532 * Fix lint * Fix test lint * DNM: test with ignis patch * Revert "DNM: test with ignis patch" This reverts commit ac9611c. * Use ignis from source for tutorial job * Update release note to be more clear
ElePT
pushed a commit
to ElePT/qiskit-algorithms-test
that referenced
this pull request
Jul 17, 2023
…it#5619) * Wrap qiskit.Aer and qiskit.IBMQ with lazy loading object This commit migrates the qiskit.Aer and qiskit.IBMQ module attributes to be lazy loading instances of lazy loading wrapper classes. The intent here is to avoid importing from qiskit-aer or qiskit-ibmq-provider from qiskit-terra, while this is safe while the packages share a shared namespace we've been actively working to remove the use of namespace packaging (see Qiskit/qiskit#5089, Qiskit/qiskit#4767, and Qiskit/qiskit#559) and the circular dependency caused by re-exporting these attributes is blocking progress on this. By using a lazy loading wrapper class we avoid an import type circular dependency and opportunistically use qiskit-aer and/or qiskit-ibmq-provider at runtime only if they're present after everything is imported. This also may have some benefit for the overall import performance of qiskit (being tracked in Qiskit/qiskit#5100) as it removes qiskit-aer and qiskit-ibmq-provider from the import path unless they're being used. Although the presence of qiskit.__qiskit_version__ might prevent any performance improvements as it still imports all the elements to get version information (and will be tackled in a separate PR). Fixes Qiskit/qiskit#5532 * Fix lint * Fix test lint * DNM: test with ignis patch * Revert "DNM: test with ignis patch" This reverts commit ac9611c3ace30d101a70bda06e1987df14662182. * Use ignis from source for tutorial job * Update release note to be more clear
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Summary
Namespace packages are constant source of problems for users. The python
packaging ecosystem around splitting packages across namespaces is
fragile at the best of times and can often leave a you with an
environment that isn't recoverable (especially when mixing install
methods). There is also a performance hit whenever there is a piece of
the namespace we allow external packages to extend since it requires
doing a full python path search which can be slow depending on the
backing I/O and the number of paths in sys.path for an environment. This
commit starts the process of addressing this by removing the arbitrary
namespace hook points and hard coding the element namespace maps via a
custom import loader at the root of the namespace. This has 2 advantages
it removes the use of namespace packages so the fragility and
performance impact are fixed since every element will be renamed to use
'qiskit_' instead of 'qiskit.', but it also makes it explicit where we
extend the namespace. The previous method allowed any package to extend
qiskit.* and qiskit.providers.* with whatever they wanted.
We'll need to coordinate updating the elements with this merging,
because it is a breaking change for each element (although not for end
users).
A potential follow on is to add a plugin interface for 3rd party
providers like what was proposed in #1465 so that we can make external
providers externally discoverable without needing to add manual hook
points moving forward (this was done for backwards compat with the aqt
and honeywell provider).
Details and comments
Fixes #559