MatthewReid854/reliability

[tag][update pip]

Closed this issue · 5 comments

lcc commented

This repository has 3 different tags: Setup.py indicates this lib is in version v0.5.4, while github releases has v0.5.1 and PyPi inidicates v0.5.3. Could you update all of those to v0.5.4?

What you see on GitHub is currently in development. I push updates to it whenever I finish a new section or update an existing section. With this in mind, the setup.py file on GitHub says 0.5.4 because that is what will be released next. As soon as I release 0.5.4 on PyPI I'll update the setup file on GitHub to say 0.5.5.

Python users should always take the version on PyPI as the most recent release. I will update this to 0.5.4 when the library is ready for the next release. If you check the changelog you can see it is scheduled for mid-November.

The Github release of 0.5.1 only exists to satisfy the DOI link provided by Zenodo. I couldn't get a DOI unless I made a GitHub release. I do not believe anyone should use a GitHub release instead of a PyPI release so I did not see the reason for updating the GitHub release to 0.5.2 or 0.5.3 when I did their respective PyPI releases. Are GitHub releases used by anyone for Python packages?

lcc commented

Are GitHub releases used by anyone for Python packages? Yeah, I guess not.

I do not believe anyone should use a GitHub release instead of a PyPI release I agree with you and understand this decision, but one could argue that since you are already using both, only keeping one updated can be confusing.

Also, IMHO you should have a developement branch (with 0.5.4 on it's setup.py) and keep the master code as the one that was published. I believe this is the "standard" way of doing things.

P.S. I sent this message because using FitEverything with the failures parameter equal to [40, 40, 40] caused the application to crash, when trying to find the root of the problem I decided to take look at the code and I believe you fixed it at 542be7a. My intention was to use the newer version, and that was when I found out about these discrepancies.

GitHub hosts my development branch. PyPI hosts my production / release branch.
Some software that is released entirely on GitHub may use development and production branches but I've never seen it done for a Python package. If you can find a Python package that uses development and release branches that are both hosted on GitHub, let me know.

Yeah, maybe I should update the GitHub release each time, but I don't see the point if no one uses it over PyPI. It shouldn't be a source of confusion when PyPI exists.

Regarding your use of Fitters.Fit_Everything with failures=[40,40,40], it will still cause an error but the error is now more specific in 0.5.4. The error will now say 'The minimum number of distinct failures required to fit everything is 2.' The key here is "distinct" failures. You can't use [40,40] as that's only 1 distinct failure time, but [40,50] would be fine. This was not correctly error checked in 0.5.3 and below as it just checked len(failures) rather than checking the number of unique failures.

lcc commented

If you can find a Python package that uses development and release branches that are both hosted on GitHub, let me know. Yeah I did a quick search at some of my top used repositories and I couldn't find any, I guess it makes sense to keep it as it's.

Yeah, maybe I should update the GitHub release each time, but I don't see the point if no one uses it over PyPI. It shouldn't be a source of confusion when PyPI exists.
Github releases can be used as a point of reference for the code, so it's easier to find the source for the desired release. I think this even eliminates the need to separate the development and production branches. I know that pandas and numpy already do this.

Oh and thanks for the feedback on Fitters.Fit_Everything.

I'll update the GitHub release when I do a PyPI release just to keep things standardized.