Conversation
TeresiaOlsson
requested review from
JeanLucPons,
gubaidulinvadim and
simoneliuzzo
docs/getting-started/installation.md
Outdated
| ============ | ||
|
|
||
| To write... | ||
| Since the code is still under development the best option to get the latest version is to install directly from github. |
There was a problem hiding this comment.
I would not say so. To actually run examples one would need to install tango-pyaml or pyaml-cs-oa that could be tied to a particular version of pyaml. I would say that the best option for a user is to install via pip a specific version. (0.x.y).
There was a problem hiding this comment.
For the future definitely yes. Then you also want to be able to control the version yourself. But do we already have a release workflow for all three repositories where we can release versions on pypi as frequently as required when the code is changing as often as it is currently doing? My feeling is that we aren't there yet and it would be part of the roadmap after the workshop to build the release workflow.
There was a problem hiding this comment.
In fact we have rules on PyPI for pyaml and tango-pyaml but not for pyaml-cs-oa at the moment.
Rules are defined in a discussion from guillaume. release are deployed on PyPI at each release tags.
https://pypi.org/project/accelerator-middle-layer/
https://pypi.org/project/tango-pyaml/
But I agree that we are still at a very first stage of the dev so cloning from main can be required.
There was a problem hiding this comment.
The problem is that currently there is no CI/CD workflow to verify that the changes in one repository did not break compatibility with the other one. And versioning is the current solution to the problem. It is possible to list that, for example,
pyaml: 0.2.1
pyaml-cs-oa: 0.1.0
tango-pyaml: 0.3.2
are the compatible versions in the pyproject.toml. Then when there's a change in the version of pyaml, before doing the version bump one needs to check compatibility. We introduced versioning to resolve this issue of breaking the codes when everyone is using the latest develop branch of each repository. Also, for the workshop @gupichon @patrickmadela and others at SOLEIL will fix the version on which everyone will start working during the workshop because we need to test beforehand that everything is working for that specific version and there's no change of the interface for the configuration files, for example.
There was a problem hiding this comment.
Maybe what we need is one way to install for users where they install everything from pypi based on version numbers and a second way to install for developers where they get all the version from the main branches on github?
There was a problem hiding this comment.
I agree, in any case, for developer, an install from main branches is required, as it would be great that some PRs emerge from this workshop.
There was a problem hiding this comment.
I'm also planning to add to the docs a dedicated developer installation instructions because there are also things like which type of doc string to use etc that we should start to document somewhere better.
So what do you think about this?
-
We make user installation instructions where everything is installed from pypi. Then we need to first make a release of pyaml-cs-oa too. Does anyone have time to do this before the workshop?
-
We make separate developer installation instructions including how to clone, install in editable mode etc. For this I think we need to fix the problem with the editable installation of tango-pyaml.
docs/getting-started/installation.md
Outdated
| The available bindings are: | ||
|
|
||
| - **tango-pyaml**: For TANGO. | ||
|
|
||
| ``` | ||
| pip install .[tango-pyaml] | ||
| ``` | ||
|
|
||
| - **pyaml-cs-oa**: For TANGO or EPICS using `ophyd-async`. | ||
|
|
||
| ``` | ||
| pip install .[pyaml-cs-oa] | ||
| ``` |
There was a problem hiding this comment.
This is fine. I just note that before it was the inverse. One was installing tango-pyaml to get pyaml. This is also fine, but it is not good to put a git repository in pyproject.toml at this stage. The codes are on pip, it is better, in my view, to install a specific version that is known to be compatible.
There was a problem hiding this comment.
Exactly, that's what I want to change. @simoneliuzzo and I tested the current way where you are supposed to go to the binding and install from there and it was very confusing. Especially if you are a TANGO lab and might want to install both bindings to compare how they work. That's why I'm suggesting to reverse it. Then you install pyaml and at that point decide which bindings you want to install by using the optional dependencies. And if you are only interested in using the simulator, you just don't install any bindings at all. Then it's the same entry point for the user independently of what they want to do.
I think having a git repository in the pyproject.toml during the development stage isn't a major problem but it is a bit annoying... If I have understood correctly it is @kparasch s plan to also include pySC like that to remove the need for the git submodules?
But this can be changed as soon as we have a release workflow for all repositories. As far as I know pyaml-cs-oa isn't on pypi yet? For the other packages, how often are they released?
There was a problem hiding this comment.
No issue with swapping the current way for me. You bring valid points. pySC was fixed to a specific commit, which for me isn't a problem because it is then a static code. (I guess @kparasch didn't have any release process for pySC at the moment). For other codes the versions are done on an "as needed" basis. The important versions are the ones that break the backward compatibility.
The main problem of installing the latest commit is that when people will be running tests and trying something, they can only tell you that they've tested with dzs32cs commit, which is not very convenient. It is better to say that "test was done with pyaml 0.1.0 and tango-pyaml 0.1.0". That's why I would like to have several installation options. The default one via pip; and then you can make a .[dev] that will install on the latest commits. But this second version is for active developers.
There was a problem hiding this comment.
I agree. I like that too. I will modify to separate user and developer installation. But we need to also make a release of pyaml-cs-oa before the users can completely install from pypi.
…per installations.
|
I have updated the installation instructions everywhere and separated user and developer instructions. The user instructions won't work until a new release is made of the package on PyPI. @gubaidulinvadim, @simoneliuzzo and @JeanLucPons, can you review again now? |
3 participants
I think our current installation instructions where the user is supposed to go to the repository for the bindings they want to use and install from there is too confusing. I think it makes it easier to understand if they are supposed to install the
pyamlrepository but with optional dependencies. Then there is the same entry point for installation independently of which control system you have.I have updated the
pyproject.tomlto include that. For now it temporarily is installing directly from the github repositories.I also added the steps to install like this to the docs.
What do you think? Is this a bad idea or you think it would help?