Jdcal is unpinned!

Issue #549 invalid
Christopher LoCoco
created an issue


It seems like jdcal is going back into development after a long hiatus. Currently they just had a mishap where they accidentally deleted the long existing 1.0 release and now have a 1.2 release instead. I noticed your library uses jdcal, but does not have it pinned, so I recommend modifying your setup.py to include a jdcal==1.2 pin in your requirements.

Relevant github issue can be found here: https://github.com/phn/jdcal/issues/5#issuecomment-155649490

Comments (24)

  1. Christopher LoCoco reporter

    Apologies, I meant to mark this as an enhancement.

    And pinning your versions in your setup is not only wise to prevent you from unexpected behavior, but also just good practice.

    If your setup already had a pin, I would agree to pinning only when there are api changes, but currently you are always pulling in latest, and with development resuming, that is not always a safe assumption.

  2. Christopher LoCoco reporter

    I think you misunderstand what happened with the library. The owner of the library incorrectly deleted the 1.0 version which has been on the central index since...2012 I believe. This means that anyone pinning a requirement to maintain a stable build environment because you haven't yet will break because jdcal==1.0 is gone and will never return.

    Pinning your requirements is the mark of a mature library, and there is zero reason why you should wait. Do you want me to PR the 5 character change myself for you?

  3. Christopher LoCoco reporter
    • changed status to open

    Opening again, as waiting for a api release is a poor excuse for pinning a requirement you have on an esoteric library that suddenly resumed development after 3 years with a developer that is new to the python library scene.

  4. Prasanth Nair


    Author of jdcal here.

    I apologize for the inconvenience.

    I happened to delete the file jdcal-1.0.1.tar.gz on pypi, and only then realized that I can't upload another file with the same name. Pypi prevents uploading a new file with the same name as an old file, even if the old file is deleted. There is apparently no way I can get jdcal-1.0.tar.gz back up on pypi. So any installation that depends on "jdcal==1.0" will fail at the pip install stage. We have to do either jdcal==1.0.1 or jdcal==1.2.

    NOTE: you have to make changes only if you have pinned a version. Otherwise pip will pick up the latest version, which is 1.2 and fully compatible with 1.0, and that will always be available.

    This is completely my fault. And that is why I am keeping this issue (https://github.com/phn/jdcal/issues/5) open on github, and commenting here, to give the issue as much visibility as possible.

    Once again, sorry for the inconvenience.

    Sincerely, Prasanth


    The reason why I deleted the file was because the last time I tried it (in 2011) I hadn't encountered any problems. In the intervening time period pypi had changed their policy. I hadn't worked with pypi at this level (i.e., uploading new versions of code) since 2012 or so (due to personal reasons) and just went with my previous experience. Why resume after 3-4 years, when there is no need for code change? Someone asked me to add a LICENSE.txt file (https://github.com/phn/jdcal/issues/4) and I wanted that change to propagate to pypi. In hindsight I should have created 1.0.1 with LICENSE.txt, without deleting 1.0. Lesson learned!

  5. CharlieC

    @Prasanth Nair First of all thank you very much for your library. It means we don't have to maintain this kind of code ourselves. Secondly, there is no need to apologise as we have no problems. This is an erroneous storm in a teacup. We all get things wrong with PyPI and until "warehouse" is ready we'll just have to live with it.

    As you rightly point out there is no need to pin your library: openpyxl will work fine with jdcal 1.0.0, ,1.0.1 and 1.2.0. Pinning should only be used when there is known incompatibility with a particular version of a library due to something like an API change. Pinning to 1.2.0 would also be wrong because it would prevent any future bug releases from being used.

    Pinning makes more sense when deploying something. But this is why there is requirements.txt which is not part of a library.

    So, thanks again for your library.

  6. Christopher LoCoco reporter

    @CharlieC : As you are a component library the best practice is actually for you to pin a range which you have tested over to make sure your library works as intended with those upstream components you consume.

    You have no idea that your code will work perfectly with jdcal (or any other given dependency) 1.2.1 or 1.3.0 or 2.0.0 because you haven't tested it. Assuming that you are going to forever be forward compatible with a library you consume is short-sighted at best.

    In addition, in real build systems in order to maintain stability, we need to pin things, but that isn't always as easy as it should be due to systems like wheel. Take for example the current issue matplotlib is having with numpy. Numpy released version 1.10.1, but matplotlib breaks past versions 1.9.x. Sure, you can fix this with using a build environment where you specifically pin your numpy version before you install your matplotlib, but then that breaks the functionality of wheel. Wheel installs every package in a vacuum, listening only to the dependencies listed by the library. So if you try to wheel matplotlib right now, you are hosed. Enjoy your added 10-15m of build time for it to re-download and reinstall both numpy and matplotlib every time you want to do a new build.

    My point is that not pinning your dependencies makes this dangerous for systems to use this library in production. Please listen to your community and don't just dismiss someone because you don't agree with them.

    Again, please pin this package to a range which you have tested and are certain will always work with your library, in this case:

  7. Kimmo Ahola

    Currently just doing

    pip install openpyxl==2.3.0

    will result to a different set of packages installed depending when the command was executed.


    We (the users of openpyxl) now have to fix this ourselves. Pinning jdcal to requirements.txt along with openpyxl is the workaround:


    That will prevent pip from installing some random version of jdcal.


    Downside is that this will result to us hoping that the version we pinned is the same as the maintainers of openpyxl used in tests and during development. And also to hope that the bug reporters have the same jdcal version as the maintainers of openpyxl.

  8. CharlieC

    Please stop reopening this. I do not agree with your assessment of the situation. This is not a bug and does not need fixing. As for invoking "community", it looks like a community of one.

  9. Christopher LoCoco reporter
    • changed status to open

    @CharlieC So far three different people using this software in production systems have spoken up to the same sentiment. The consensus on stack overflow is to pin your requirements. PEP 426 suggests pinning your requirements. This is not my solitary opinion, it is born out of listening to the best practices suggested by the python community at large. In addition, this issue has 2 votes 7 watchers, so even in the small space of this issue, I am not alone in this request. I made the change for you already. This helps the stability of your library and will please those of us who use it in a production environment. I implore you to reconsider.

  10. Christopher LoCoco reporter

    Sorry, then 2 in this thread and the massive repository of wisdom from the community at large about proper maintaining of a library.

    As @Kimmo Ahola mentioned, there is a workaround, but it means we are no longer sure we are using what you are using when you are testing, which means our production servers have added risk.

    It is clear you are going to be stubborn and not implement this very simple thing which would improve the quality of your library for users, like the organization I work for. What worries me is that you think this a "fictitious problem," in the face of the multiple resources I have provided.

  11. Log in to comment