simphony/simphony-osp

Publish OSP-core in PyPI

kysrpex opened this issue · 6 comments

kysrpex commented

Discussed in #686

Originally posted by yoavnash May 20, 2021
Publish OSP-core in pypi to enable easy installation of the package.

Options for the project name:

  1. pip install simphony
  2. pip install osp-core
  3. pip install simphony-osp-core

Option 3 has the advantage of being able to extend for wrappers. For example: pip install simphony-wrapper-simlammp.

Relevent links:

csadorf commented

It's extremely annoying that this package cannot be installed via PyPI. What is the reason for not doing this immediately?

kysrpex commented

It's extremely annoying that this package cannot be installed via PyPI. What is the reason for not doing this immediately?

The reason is the combined effect of:

Changing the package name is a major change, which according to semantic versioning should involve a major version change. Why? Because as soon as you change it, the installation of wrappers will fail (as they depend on the package osp-core). It would not be acceptable that you come here, download an update with the same major version number, and things stop working, even if the issue is trivial to solve.

Considering that a new major version with breaking changes is coming relatively soon, the possible solutions are:

  1. Publish a new major version in which only the package name changes (and possibly the names to import in order to use it). Then publish the other new major version with the breaking changes.
  2. Publish the new major version both with the new package name and the changes.

We have decided to do the second, which we see as less confusing for the users, even if it delays the publication on PyPi. Sorry if meanwhile it is an inconvenience. We are aware of it and as you see publishing it is in our plans.

csadorf commented

@kysrpex Thank you for responding. I agree that changing the namespace constitutes a breaking change, but I really don't follow the issue. To me this appears extremely simple:

  1. You publish version 3.6.1 on PyPI under the project name "simphony-osp" with the current module name(s) and namespaces.
  2. Later you publish version 4.0.0 with the updated module name and other updates.

Distributing a package on PyPI should not constitute some kind of "major" step in the history of a tool that is seemingly in development for a long time (4-5 years?) and should be used by more than a handful of users. It's simply the standard distribution mechanism for Python packages and IMO should be one of the first things you do once the package has been published open-source. Frankly, I think you overestimate the amount of confusion a module name change might create in comparison to the amount of confusion this somewhat arbitrary delay in adopting standard package distribution mechanisms is creating. Who exactly do you expect to be confused by this considering that the package is already released on GitHub? Just my 2 cents, feel free to ignore. 😉

Do you already have a timeline for the 4.0 release?

kysrpex commented

@kysrpex Thank you for responding. I agree that changing the namespace constitutes a breaking change, but I really don't follow the issue. To me this appears extremely simple:

1. You publish version 3.6.1 on PyPI under the project name "simphony-osp" with the current module name(s) and namespaces.

2. Later you publish version 4.0.0 with the updated module name and other updates.

Distributing a package on PyPI should not constitute some kind of "major" step in the history of a tool that is seemingly in development for a long time (4-5 years?) and should be used by more than a handful of users. It's simply the standard distribution mechanism for Python packages and IMO should be one of the first things you do once the package has been published open-source. Frankly, I think you overestimate the amount of confusion a module name change might create in comparison to the amount of confusion this somewhat arbitrary delay in adopting standard package distribution mechanisms is creating. Who exactly do you expect to be confused by this considering that the package is already released on GitHub? Just my 2 cents, feel free to ignore. wink

Do you already have a timeline for the 4.0 release?

Thank you for your reply. Indeed points 1 and 2 are extremely simple. Maybe I failed to communicate the issue properly. What I am trying to say is that

You publish version 3.6.1 on PyPI under the project name "simphony-osp" with the current module name(s) and namespaces.

breaks the installation of the wrappers. Take a look at the setup.py from a wrapper. As soon as I change the package name, this line will cause a failure (or am I missing something here?), even if trivial to solve by the wrapper developer.

I am not saying that publishing on PyPI is a "major" step in the sense of the steps taken by the project. It is indeed a super tiny step. I use the word major, because major in semantic versioning means:

MAJOR version when you make incompatible API changes,

Which is what I am doing by breaking the wrapper installation.

you overestimate the amount of confusion a module name change might create in comparison to the amount of confusion this somewhat arbitrary delay in adopting standard package distribution mechanisms is creating. Who exactly do you expect to be confused by this considering that the package is already released on GitHub? Just my 2 cents, feel free to ignore. wink

Yes, it can be the case that I do the wrong estimation here. Thank you for pointing it out.

csadorf commented

I understood what you meant by major. I should have used the terms "significant", "big", or "consequential" to avoid the confusion.

I see your point with respect to breaking the wrapper installation and I also failed to consider that changing the distribution name would of course require to create a new version, so you can't distribute 3.6.1 under the simphony-osp project name. So I guess the only other alternative you have seemingly not really considered is to simply distribute the 3.x line under the name osp-core instead. That's the current name of the distribution, would also help your current users, and does not break any scripts (now and in the future).

Do you already have a timeline for the 4.0 release?

👆

kysrpex commented

the only other alternative you have seemingly not really considered is to simply distribute the 3.x line under the name osp-core instead. That's the current name of the distribution, would also help your current users, and does not break any scripts (now and in the future).

I did indeed not consider that option 🤣 After thinking about it, I see no downsides and only benefits. Expect to see osp-core in PyPI soon 😉.

Do you already have a timeline for the 4.0 release?

The timeframe we have in mind is 2-4 months.

  • 🎉2