Question: rename prompt_toolkit to prompt_toolkit2 or not? (during a transition period). #568
Comments
|
I personally would be a fan of this |
|
From this discussion in SO, it looks like installing 2 versions side-by-side is quite a pain: https://stackoverflow.com/questions/6570635/installing-multiple-versions-of-a-package-with-pip Are we assuming that during the transition period, only the users who want to try out the latest and greatest (beta testers) will be using 2.0? Those users should be ok with going an extra step and creating a venv. Then, there's no need to rename the package. |
|
No, the idea is that all applications will slowly transition to 2.0. So, not just the beta testers. The idea is that during this transition period, there won't be any collisions between both versions in whatever environment. Only when most packages are using 2.0, I'd push another release with the name "prompt_toolkit" instead of "prompt_toolkit2". The only thing which remains at that point is to remove the 2 suffix in these applications. |
|
How about we react with 👍 to your initial comment in this issue for "rename", and with 👎 for "do not rename"? I added my 👍 . |
|
I like the idea of using prompt_toolkit2. It provides a safe transition phase and there is nothing wrong with adding the digit 2 to the library name. |
|
If you decide to rename it, I strongly suggest not planning on doing a name reversion in the future. The time when "most packages are using 2.0" is a fuzzy, hard to specify point: there will be stragglers who you only find out about if they accidentally get pulled into the 'new' prompt-toolkit name after the rename. Either bite the bullet with a 2 on the long name and live with it for the long run, or find another name you like as you move forward. But doing pt -> pt2 -> pt as names is only going to create chaos and grief, I suspect (and you'll be the one dealing with the ugly side of that grief :) Just a thought... Thanks again for the great tool! |
|
My vote is to not rename. Packages with numbers in their names tend to be confusing. And version pinning isn't that hard. Conda at least will prevent 2.0 from being installed if an installed package requires 1.0. Linux package managers should work that way too (pip might not be as smart, but maybe it's better these days?). I have a question though: how hard will it be for things like ipython to support both versions in the short term? |
|
This may seem like an silly question but why would anyone want two versions of PT installed in the same place at the same time? PT2 either works or it doesn't. If it doesn't then why have PT2 around? My gut tells me that if you do a PT2 package (instead of an PT version 2.0a1, 2.0b1 etc) you'll have to live forever with the reality that people will depend and keep using the PT2 package, and complain if you suddenly not release PT2 anymore and go back to PT. |
|
@ionelmc's comment about "you'll have to live forever with the reality that people will depend and keep using the PT2 package, and complain if you suddenly not release PT2 anymore and go back to PT" makes me change my vote. 🤔 |
|
I can't make a recommendation without a lot more details about what the changes are, but I agree that the two realistic options are: (1) keep the name, tell people to pin-or-not, (2) change the name and treat it as a permanent name change. The first is reasonable if you expect everyone to be able to transition pretty easily; the second is good if you have a more fundamental API change and expect the two versions to coexist in a substantial way. The problem with changing back from PT2 → PT is now instead of one hard breaking transition, you have two, and the second is totally gratuitous for most people. |
|
I just want to point out that even if pip can install 2 versions of the same package, other packages managers may not be able to. So this hing for a renaming. One other possibility that has not been mentioned it to back-publish a prompt_toolkit_legacy or prompt_toolkit_1, which is strictly identical to already released version(s) and is a simple search-and -replace away for software that will adopt version 2. Keep in mind that now applications have many dependencies, and even if prompt toolkit have 2 versions, some other packages may conflict as well and 2 CL tools may still not be installable at the same time. |
|
I am for "biting the bullet" and just switch. But I do support @Carreau's idea of creating a prompt_toolkit_legacy package and encouraging the most important packages that use ptk to update with that first before switching to 2.0.... |
|
Renaming the old version of prompt_toolkit will break all projects that depend on it, that will be as destructive as just releasing prompt_toolkit 2 with the same name. I'd prefer python_toolkit2 and stick with that name. |
@meeuw... Yes. But it could be done right now. Giving all projects a little more time to adapt until ptk2 is released. It, of course, depends on how far the PTK2 release is away. I think it would be a shame to rename the PTK project. I have always thought the python/python3 scheme on Linux was very silly. |
|
I fully agree with what Nathaniel said. Don't complicate it with transition
periods or renaming version 1. The options that make sense to me are: keep
the same name, or call the new one prompt_toolkit2 and stick with that.
If you expect that we'll mostly be able to make some changes to our code
and have it work with the new version, keep the name and bump the version
number. That's what we'd expect for a 2.0 release. If we'll need to start
again figuring out a new interface, then a rename sounds appropriate.
…On 24 Dec 2017 7:25 a.m., "Morten Enemark Lund" ***@***.***> wrote:
Renaming the old version of prompt_toolkit will break all projects that
depend on it, that will be as destructive as just releasing prompt_toolkit
2 with the same name.
@meeuw <https://github.com/meeuw>... Yes. But it could be done right now.
Giving all projects a little more time to adapt until ptk2 is released. It,
of course, depends on how far the PTK2 release is away. I think it would be
a shame to rename the PTK project. I have always thought the python/python3
scheme on Linux was very silly.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#568 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAUA9Q54dzW31i5gOzBhdWXRnQIs7Nmjks5tDfxVgaJpZM4RKYwZ>
.
|
|
Thanks, everyone! I really appreciate all the feedback. I think this means we should not rename, but I'm giving it some more time. Here is some more info about why we have these breaking changes and what's new: https://github.com/jonathanslenders/python-prompt-toolkit/blob/2.0/docs/pages/upgrading.rst Have a merry Christmas and good end of year! |
|
I also vote not to rename. Even though applications can break if two apps depend on different versions of prompt_toolkit, users should be able to fix it by creating two separate virtualenvs. People using these apps are developers, they should be able to do that without too much effort. |
|
@Fale I believe you're the Red Hat / Fedora package maintainer for prompt_toolkit, could you please give your opinion about this? |
No I was not suggesting renaming the old version. I was suggesting re-releasing prompt_toolkit version 1 under another name, so that packages that packages that do not want to spend time upgrading can just require this new version and a do a search an replace. Same a readline which is also available a gnureadline but is otherwise identical. That does not need to be decided now as it is relatively easy to do. |
|
I was interested in reading all the the contributions to this topic. But now I can't hold on ;) Using Semantic Versioning scheme, changed APIs are released with major versions. This is what PT v2.0.0 means (see here). If a project needs API from major release v1.m.p it has to stick such dependencies (see Compatible Releases). The question I miss; are there any patch-levels (branches) are planed for v1, or will it be a version tag? .. these are my 2 cents, hope it helps to clarify |
|
@return42: it is possible that certain bug fixes will still be applied to the 1.0 branch, but I'd like to move as much as possible to the 2.0 branch. Maintaining two branches takes a lot of time. |
|
If you need/want to backport, I can enable the Jupyter bot on your repo.
When an appropriately milestoned pr is merged in master, it autogenerate
the pr with the backport.
…On Dec 30, 2017 19:56, "Jonathan Slenders" ***@***.***> wrote:
@return42 <https://github.com/return42>: it is possible that certain bug
fixes will still be applied to the 1.0 branch, but I'd like to move as much
as possible to the 2.0 branch. Maintaining two branches takes a lot of time.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#568 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAUez43xiLAxU5eu98YYhTpE2QgFJGF2ks5tFodWgaJpZM4RKYwZ>
.
|
|
Stick with the current name. Package managers should deal with this issue by setting a proper version range. |
|
I'd vote for renaming it. As a large number of users are ipython users which do not know how to install two versions of a package. Restricting themselves to 1.0 means that they will not be able to install tools which uses prompt-toolkit 2.0. |
|
Ipython will probably upgrade to pt version 2 when it's available.
On 29 Jan 2018 6:44 p.m., "Randy Lai" <notifications@github.com> wrote:
I'd vote for renaming it. As a large number of users are ipython users
which do not know how to install two versions of a package. Restricting
themselves to 1.0 means that they will not be able to install tools which
uses prompt-toolkit 2.0.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#568 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAUA9Spp4b79LrrS6QRxJ64rRCVVAmUWks5tPhGOgaJpZM4RKYwZ>
.
|
|
Maybe a third option might be to create a deprecated adapter for the version 1 style API. When user use this API, a deprecation warning is given. |
|
How difficult would it be to just add legacy API adaptors which include a warning and a transition date a year from release? Then there is no breakage, no rename. :-) A great example of this is in Keras https://github.com/keras-team/keras/tree/master/keras/legacy |
|
Another example is in the django project where api's are deprecated for several versions. |
|
Hi everyone, I just released prompt_toolkit 2.0.1. Please let me know if you have any issues upgrading your applications! Cheers, |
Hi everyone,
I'm opening this issue to discuss whether or not we should rename
prompt_toolkittoprompt_toolkit2.The problem that we are facing right now is that we want to release version 2.0, but it's backwards incompatible with 1.0. This would normally not be an issue, because the best practices tell you to install Python applications in a virtualenv. However, most prompt_toolkit applications are system tools, which are often installed with the system wide Python installation, and very often these are distributed through other channels like the repositories of Linux distributions. We don't want to break those.
As I understand it, setuptools can install multiple versions of a package alongside each other. There is a
__requires__variable that is inspected by pkg_resources to make sure the right version of the package is loaded. (See, e.g.: https://stackoverflow.com/questions/13720065/what-does-requires-mean-in-python ). However, I'm not sure how well this works in practice.While I don't like it, if renaming this library to
prompt_toolkit2during a transition period is the only way to solve certain issues, then I'm in favor of doing it. The intend is to rename it back toprompt_toolkitwhen most applications are transitioned. (At that point,prompt_toolkit2could remain an alias forprompt_toolkit.)I don't have much personal experience with issues like this, so all feedback is welcome.
The text was updated successfully, but these errors were encountered: