I don't think we should have the package version depending on which package set is evaluated. In my opinion the proper solution is for the user to override the package set setting ipython = ipython_5;.

This is an option, but it is suboptimal because packages dependent on ipython will not be built and tested under Python 2.7, and because it is a job of each of python*Packages to provide a consistent set of packages: if their versions in python2Packages must be different from their versions in python3Packages, so be it.

I grant that the proposed pull request is not as generic as might be required in the future when more packages that currently support both interpreters drop support for Python 2 or Python 3, but it is better for the user and currently fulfills the intended quality of python2Packages and python3Packages.

We can discuss having a ipython = if isPy27 then ipython_5 else ipython_6; instead of overriding the attribute (e.g. through an overlay) but in any case the expression for 5 has to be in a separate file as is common in the Nixpkgs repo.

This is an option, but it is suboptimal because packages dependent on ipython will not be built and tested under Python 2.7, and because it is a job of each of python*Packages to provide a consistent set of packages:

Only dependents of ipython are the kernel ipykernel and some other Jupyter packages. The next version of the notebook is going to drop 2.7 support.

if their versions in python2Packages must be different from their versions in python3Packages, so be it.

Sure, but by adding a different version you create a whole new tree with potential issues.

but it is better for the user and currently fulfills the intended quality of python2Packages and python3Packages.

That I agree. We can see for now how it goes with multiple versions.

We can discuss having a ipython = if isPy27 then ipython_5 else ipython_6; instead of overriding the attribute (e.g. through an overlay) but in any case the expression for 5 has to be in a separate file as is common in the Nixpkgs repo.

Ok, see the updated pull request. (I prefer ipython5 to ipython_5 because it is much more common to append the major version without underscore, and ipython to ipython_6 because there would be no ipython_6 without the need to support Python 2.7.)

Only dependents of ipython are the kernel ipykernel and some other Jupyter packages.

There are at least ipdb, ipdbplugin, spyder…

The next version of the notebook is going to drop 2.7 support.

Ok, but is there consensus that nixpkgs should drop support for a Python 2.7 version of the package as soon as upstream releases a version of the package incompatible with Python 2.7? What if upstream still maintains a Python 2.7 branch with bugfix releases? I'd guess that quite a lot of people need IPython Notebook for Python 2.7 (maybe more than for Python 3).

Ok, but is there consensus that nixpkgs should drop support for a Python 2.7 version of the package as soon as upstream releases a version of the package incompatible with Python 2.7?

Should there be consensus? In Nixpkgs it is up to the maintainers of packages and package sets to decide what happens with the code they maintain. Of course, it is a community project, and so it makes sense they take into account the feedback from the community, but in order to do so they need to first get feedback.

In this case its quite simple; as maintainer I've sent out an e-mail explaining the ipython situation and my intention and I didn't get any feedback. Now, though, @LnL7 and @orivej brought up the issue so there's something to take into account.

I'd guess that quite a lot of people need IPython Notebook for Python 2.7 (maybe more than for Python 3).

That's very likely, but then they need to speak up, write expressions, and maintain them.

Now, on to the details of your current PR.

(I prefer ipython5 to ipython_5 because it is much more common to append the major version without underscore

If you want to discuss the naming of attributes, see #17625. In python-packages.nix the convention is name_X_X.

and ipython to ipython_6 because there would be no ipython_6 without the need to support Python 2.7

Again, convention. Ideally, we wouldn't have multiple versions of any package in python-packages.nix because we do not want to risk mixing versions of packages inside a closure. Unfortunately, it sometimes happens we do need multiple versions, in which case we add an attribute for each version, and a main attribute that one can override to obtain the other version.

Of course, if you maintain the 5.x version you could choose to add disabled = isPy3k;, but at least the expression is there for one to override and use it.

+1 for having ipython that works with python 2.x as long as upstream supports it (if it's not too much work).

I opened the issue before I noticed the email on the mailing list 😄 . Since I only use ipython for development I don't really care if it's only exposed with a version suffix, but I'd be happy to help maintain it.

@LnL7 I have just listed you as a maintainer in the pull request.

In this case its quite simple; as maintainer I've sent out an e-mail explaining the ipython situation and my intention and I didn't get any feedback.

I have subscribed to the mailing list after reading #25234 (comment) so I hope not to miss future announcements.

If you want to discuss the naming of attributes, see #17625. In python-packages.nix the convention is name_X_X.

I have classified the names in python-packages.nix and here, as in all-packages.nix, the status quo is to join a single version component without separator and to join multiple version components with an underscore:

Single component:

• underscore
  amqp_1
  click_5
  kombu_3
• adjacent
  beautifulsoup4
  boto3
  zc_buildout2
  deform2
  gmpy2
  pycurl2
  pyparsing1
  pyro3
  requests2
  sqlalchemy8
  tqdm4

Multiple components:

• underscore
  beautifulsoup_4_1_3
  dateutil_2_2
  dateutil_1_5
  dateutil_2_1
  pathspec_0_5
  django_1_9
  django_1_8
  django_1_6
  lxml_3_5
  mccabe_0_5
  openpyxl_2_2_0_b1
  pymongo_2_9_1
  sqlalchemy_1_0
• adjacent
  zc_buildout221
  zc_buildout171
  zc_buildout152
• underscore + adjacent
  billiard_33
• hyphen
  llfuse-0-41
• hyphen + adjacent
  boto-230

I believe that my pull request follows the convention, but if you'll say that the attribute(s) and the file(s) should be named otherwise, I'll rename them without asking for justification.

I've pushed 2efb099.

@orivej thanks for that list. I see we have a lot of old packages that we should see whether we can get rid of.

Thanks!