nasirhjafri / libyear Goto Github PK

Add a new argument --versions to measures the number of major, minor, and patch versions between your dependencies' installed and newest versions

$ libyear --versions
                 activesupport        4.2.7.1     2016-08-10          5.1.3     2017-08-03      [1, 0, 0]
                          i18n          0.8.0     2017-01-31          0.8.6     2017-07-10      [0, 0, 6]
                          json          1.8.6     2017-01-13          2.1.0     2017-04-18      [1, 0, 0]
                      minitest         5.10.1     2016-12-02         5.10.3     2017-07-21      [0, 0, 2]
             minitest_to_rspec          0.6.0     2015-06-09          0.8.0     2017-01-02      [0, 2, 0]
                   ruby_parser          3.8.4     2017-01-13         3.10.1     2017-07-21      [0, 2, 0]
                sexp_processor          4.8.0     2017-02-01         4.10.0     2017-07-17      [0, 2, 0]
                   thread_safe          0.3.5     2015-03-11          0.3.6     2017-02-22      [0, 0, 1]
                        tzinfo          1.2.2     2014-08-08          1.2.3     2017-03-25      [0, 0, 1]
Major, minor, patch versions behind: 2, 6, 10

skipping --index-url and --find-links options in the requirement files to save extra lines of code to be executed.

I was pointed at this project by a colleague, and I think it is a really cool idea! I am wanting to integrate this into a continuous integration build system that shoves a bunch of reports to a bucket to be consumed by another service in our ecosystem to track organization-wide metrics about our various codebases. Would you be open to a contribution that uses this feature from prettytable to output the data to a json format that is more machine-readable?

I am thinking it is just a refactor of these lines of code:

Also, thanks for building this!

I am trying to use libyear behind a corporate proxy and I am getting an "SSL certificate verify failed" error because it is trying to access pypi, which I cannot access directly. Is there a way of providing my own package remote URL instead of pypi? If not, should I create a PR so a user can provide one? Thanks.

requests.exceptions.SSLError: HTTPSConnectionPool(host='pypi.org', port=443): 
Max retries exceeded with url: /pypi/maq/json (Caused by SSLError(SSLError(1, '[SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:645)'),))

Many open source software packages have a license for users to evaluate whether they may use the software package in their application or tooling.

https://choosealicense.com/ is a great resource to leverage to understand what's available.

I am partial to https://choosealicense.com/licenses/mit/ - but most of them are pretty standard. The MIT is also one of the most popular, as reported by WhiteSource: https://resources.whitesourcesoftware.com/blog-whitesource/open-source-licenses-trends-and-predictions

Once chosen, this can be added to setup.py like this:

    classifiers=[
        ...
        "License :: OSI Approved :: MIT License",
        ...
    ],

Other values can be found here: https://pypi.org/classifiers/

Hi there, nice idea!

My requirements file may be allow updating to the latest version of dependencies (and so may show as up to date with libyear) but if I cache my dependencies and last updated them two years ago then the actual libraries making up my application could be hundreds of "libyears" behind current.

Is that by design, if so what is the rationale?

the README says

There are obviously more nuanced ways to calculate dependency freshness. The advantage of this approach is its simplicity. You will be able to explain this calculation to your colleagues in about 30s.

But the examples don't actually make it totally clear (at least to me).

For example, a rails 5.0.0 dependency (released June 30, 2016) is roughly 1 libyear behind the 5.1.2 version (released June 26, 2017).

OK, the relative difference is clear, but if I'm running libyear in my application which is using 5.0.0, is it going to report based on the age of 5.0.0 relative to today or relative to when 5.1.2 came out.

In 2023, if I had an app still using 5.0.0, would my libyear score be 7.13 or 6.14?

Here's a clearer scenario for me to get my question across:

• I have an application with one library as a dependency which is at version 1.0.0 which was also released the same day. When I start, that's the only (or at least current) version of the dependency. Ie, there's nothing newer I can upgrade to. My expectation at this point is that my libyear score is "0" because I'm effectively fully up to date. There's nothing for me to upgrade.
• One year goes by. The single dependency has not released an upgrade. Ie, I'm still as fully up to date as I could possibly be. My expectation again, is that my libyear score is still "0". Is that accurate, or is it now "1 year" because 1.0.0 of the dependency is a year old?
• Later that day, the dependency releases version 2.0.0. I'm still on 1.0.0. A day later, is my libyear score "1 year" because my 1.0.0 dependency is a year out of date? Or is it "1 day" because the newer version has only been out for a day?
• A week later, I'm still on 1.0.0, but dependency 3.0.0 is released. Am I now at "1 year and 1 week" or just at "1 week"?

My experience with other tools like piprot is that in that scenario it would go straight from "0" to "1 year" as soon as 2.0.0 is released, then back to "0" once I upgrade to the latest version.

Ideally though, the latter approach where the counter starts going up from zero once the new version is released is preferable. To me, that is a better representation of how far behind I am. This is especially important if I'm thinking about this as a metric that might be tracked and alerted on by an ops or security team when it crosses a threshold. Developers on the team might understand how the metric works, but from the outside, seeing a security-related metric go from 0 to 100 looks bad.

Add --releases argument to measures the number of releases between your dependencies' installed and newest versions

$ libyear --releases
                 activesupport        4.2.7.1     2016-08-10          5.1.3     2017-08-03        37
                          i18n          0.8.0     2017-01-31          0.8.6     2017-07-10         5
                          json          1.8.6     2017-01-13          2.1.0     2017-04-18        12
                      minitest         5.10.1     2016-12-02         5.10.3     2017-07-21         2
             minitest_to_rspec          0.6.0     2015-06-09          0.8.0     2017-01-02         5
                   ruby_parser          3.8.4     2017-01-13         3.10.1     2017-07-21         3
                sexp_processor          4.8.0     2017-02-01         4.10.0     2017-07-17         3
                   thread_safe          0.3.5     2015-03-11          0.3.6     2017-02-22         2
                        tzinfo          1.2.2     2014-08-08          1.2.3     2017-03-25         1
Total releases behind: 70

While uploading releases to PyPI read me file is used which looks weird on PyPI. We need a way to fix i.

As a user
Given a long libyears behind listing
When I want to prioritize some of the oldest deps
Then I should be able to sort the output accordingly

Considering the table is a PrettyTable, and there's both .sortby and .reversesort methods, this seems like it would be pretty straightforward to include.

Is this something you'd be interested in adding? I can imagine either a default sort, or allowing the user to control the sort - alphabetically too! I'd be happy to work on this.