diff --git a/docs/source/Contribution/Development.rst b/docs/source/Contribution/Development.rst index b1476fcee..b648c6aa9 100644 --- a/docs/source/Contribution/Development.rst +++ b/docs/source/Contribution/Development.rst @@ -1282,468 +1282,6 @@ for more discussion see `Which Version is stable .. `` - -Where: - -- **protocol version** is the message version. In Sarra notification messages, they are all prefixed with v02 (at the moment). -- **YY** is the last two digits of the year of the initial release in the series. -- **MM** is a TWO digit month number i.e. for April: 04. -- **segment** is what would be used within a series. - from pep0440: - X.YaN # Alpha release - X.YbN # Beta release - X.YrcN # Release Candidate - X.Y # Final release - X.ypostN #ack! patched release. - -Currently, 3.00 is still stabilizing, so the year/month convention is not being applied. -Releases are currently 3.00.iircj -where: - - * ii -- incremental number of pre-releases of 3.00 - - * j -- beta increment. - -At some point 3.00 will be complete & solid enough that the we will -resume the year/month convention, hopefully 3.22. - -Releases are classified as follows: - -Alpha - Snapshot releases taken directly from development, with no other qualitative guarantees. - No guarantee of functionality, some components may be partially implemented, some - breakage may occur. - No bug-fixes, issues addressed by subsequent version. - Often used for early end-to-end testing (rather than installing custom from tree on - each test machine.) - -Beta - Feature Complete for a given release. Components in their final form for this release. - Documentation exists in at least one language. - All previously known release block bugs addressed. - No bug-fixes, issues addressed by subsequent version. - -RC - Release Candidate. - Implies it has gone through beta to identify and address major issues. - Translated documentation available. - No bug-fixes, issues addressed by subsequent version. - -Final versions have no suffix and are considered stable and supported. -Stable should receive bug-fixes if necessary from time to time. -One can build python wheels, or debian packages for local testing purposes -during development. - -.. Note:: If you change default settings for exchanges / queues as - part of a new version, keep in mind that all components have to use - the same settings or the bind will fail, and they will not be able - to connect. If a new version declares different queue or exchange - settings, then the simplest means of upgrading (preserving data) is to - drain the queues prior to upgrading, for example by - setting, the access to the resource will not be granted by the server. - (??? perhaps there is a way to get access to a resource as is... no declare) - (??? should be investigated) - - Changing the default requires the removal and recreation of the resource. - This has a major impact on processes... - -Example: - -The first alpha release in January 2016 would be versioned as ``metpx-sarracenia-2.16.01a01`` - - -Set the Version -~~~~~~~~~~~~~~~ - -This is done to *start* development on a version. It should be done on development -after every release. - -* git checkout development -* Edit ``sarracenia/_version.py`` manually and set the version number. -* Edit CHANGES.rst to add a section for the version. -* run dch to start the changelog for the current version. - * change *unstable* to *UNRELEASED* (maybe done automatically by dch.) -* git commit -a -* git push - -If development continues and the time passes without the release occurring, then -the version needs to be set to again (or overwritten). For example, a development -cycle begins in August, the version in stable will be 3.19.08b1... but if development -continues into September, one should use this procedure the change the version to 3.19.09b1. - -note on Debian terminology: - -* unstable ... new software brought into the OS stablization tree. -* testing ... software considered stable enough to be included in the next "stable" release. -* stable ... part of a stable Debian release: frozen software that will not be patched except - for security issues. - -for Metpx-Sr3, we have not yet approached the longevity of versions implied by Debian *stable*. -The labels don't refer to how stable the software itself is, merely to how often the software -changes (increments versions.) More info: `Debian Version History `_ -so when performing releases, the changelog is changed from UNRELEASED to unstable, and -back to UNRELEASED when working between releases, as per Debian custom. - -Release Versions and Quality Assurance -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -The Quality Assurance process, or QA occurs mainly on the development branch. -prior to accepting a release, and barring known exceptions, - -* QA tests automatically keyed to pushes to the development branch should all pass. - (All related github actions.) - tests: static, no_mirror, flakey_broker, restart_server, dynamic_flow are included in "flow.yml" - -* build an ubuntu 18.04 vm and run the flow tests there to ensure that it works. - (installation method: cloning from development on github.) - tests: static, no_mirror, flakey_broker, restart_server, dynamic_flow - -* build a redhat 8 vm and run the flow test there to ensure that it works. - (installation method: cloning from development on github.) - tests: static, no_mirror, flakey_broker, restart_server, dynamic_flow - -* After that, a pre-release version is prepared. It should have an rcX suffix - publish to: https://launchpad.net/~ssc-hpc-chp-spc/+archive/ubuntu/metpx-pre-release - publish to: pypi.org (rcX suffix is detected as a pre-release.) - publish to: github.com (tag as pre-release.) - - the pre-release repository. - - * pre-release version is installed on development server. - (from launchpad repo.) - - * pre-release version is installed on some staging workloads. - i(from launchpad repo.) - - * if the pre-release version runs all configured flows without incidents for a week. - -* Then a stable version is declared, pushed to the stable repository: - - * ensure there is no rcX suffix on the version. - * publish to: https://launchpad.net/~ssc-hpc-chp-spc/+archive/ubuntu/metpx - * publish to: pypi.org (remove rcX suffix so it is considered latest.) - * publish to: github.com (tag as latest .) - -the mechanics of preparing each release are documented in the following section. - -For extensive discussion see: https://github.com/MetPX/sarracenia/issues/139 - - - - -Releasing -~~~~~~~~~ - -Prior to releasing, ensure that all QA tests in the section above are passed. -When development for a version is complete. The following should occur: - -A tag should be created to identify the end of the cycle:: - - git checkout development - git tag -a sarra-v3.16.01a01 -m "release 3.16.01a01" - git push - git push origin sarra-v3.16.01a01 - -Once the tag is in the development branch, promote it to stable:: - - git checkout stable - git merge development - git push - -Once stable is updated on github, the docker images will be automatically upgraded, but -we then need to update the various distribution methods: `PyPI`_, and `Launchpad`_ - -Once package generation is complete, one should `Set the Version`_ -in development to the next logical increment to ensure no further development -occurs that is identified as the released version. - - -PyPi -~~~~ - -Pypi does not distinguish between older and newer python releases. There is only one package -version for all supported versions. When uploading from a new OS, the versions in use on the -OS are inferred to be the minimum, and so installation on older operating systems may be blocked -by generated dependencies on overly modern versions. - -So when uploading to pypi, always do so from the oldest operating system where it needs to work. -upward compatibility is more likely than downward. - -Pypi Credentials go in ~/.pypirc. Sample Content:: - - [pypi] - username: SupercomputingGCCA - password: - -Assuming pypi upload credentials are in place, uploading a new release used to be a one liner:: - - python3 setup.py bdist_wheel upload - -on older systems, or on (python >= 3.7) newer ones:: - - python3 -m build --no-isolation - twine upload dist/metpx_sarracenia-2.22.6-py3-none-any.whl dist/metpx_sarracenia-2.22.6.tar.gz - -Should always include source (the .tar.gz file) -Note that the CHANGES.rst file is in restructured text and is parsed by pypi.python.org -on upload. - -.. Note:: - - When uploading pre-release packages (alpha,beta, or RC) PYpi does not serve those to users by default. - For seamless upgrade, early testers need to do supply the ``--pre`` switch to pip:: - - pip3 install --upgrade --pre metpx-sarracenia - - On occasion you may wish to install a specific version:: - - pip3 install --upgrade metpx-sarracenia==2.16.03a9 - - command line use of setup.py is deprecated. Replaced by build and twine. - - -Launchpad -~~~~~~~~~ - -Canonical, the company behind Ubuntu, provides Launchpad as a means of enabling third parties to build -packages for their operating system releases. It turns out that the newer OS versions have dependencies -that are not available on the old ones. So the development branch is configured to build on newer -releases, but an a separate branch must be created when creating releases for ubuntu bionic (18.04) and focal (20.04) -:: - - git checkout stable - git branch -D stable_focal_bionic - git branch stable_focal_bionic - git checkout stable_focal_bionic - vi debian/control - # remove pybuild-plugin-pyproject from the "Build-Depends" - git rm pyproject.toml - # remove the new-style installer to force use of setup.py - git commit -a -m "adjust for older os" - -There might be a "--force" required at some point. Perhaps something along the lines of:: - - git push origin stable_focal_bionic --force - -Then proceed with Launchpad instructions. - - - -Automated Build -+++++++++++++++ - -* Ensure the code mirror is updated by checking the **Import details** by checking `this page for sarracenia `_ -* if the code is out of date, do **Import Now** , and wait a few minutes while it is updated. -* once the repository is upto date, proceed with the build request. -* Go to the `sarracenia release `_ recipe -* Go to the `sr3 release `_ recipe -* Click on the **Request build(s)** button to create a new release -* for Sarrac, follow the procedure `here `_ -* The built packages will be available in the `metpx ppa `_ - - - -Building a Windows Installer -++++++++++++++++++++++++++++ - -One can also build a Windows installer with that -`script `_. -It needs to be run from a Linux OS (preferably Ubuntu 18) in the root directory of Sarracenia's git. -find the python version in use:: - - fractal% python -V - Python 3.10.12 - fractal% - -So this is python 3.10. Only a single minor version will have the embedded package needed -by pynsist to build the executable, so look at:: - - https://www.python.org/downloads/windows/ - -Then go look on python.org, for the "right" version (for 3.10, it is 3.10.11 ) -Then, from the shell, run:: - - sudo apt install nsis - pip3 install pynsist wheel - ./generate-win-installer.sh 3.10.11 2>&1 > log.txt - -The final package will be generated into build/nsis directory. - - -Daily Builds -++++++++++++ - -Daily builds are configured -using `this recipe for python `_ -and `this recipe for C `_ and -are run once per day when changes to the repository occur. These packages are stored in the `metpx-daily ppa `_. -One can also **Request build(s)** on demand if desired. - -Manual Process -++++++++++++++ - -The process for manually publishing packages to Launchpad ( https://launchpad.net/~ssc-hpc-chp-spc ) -involves a more complex set of steps, and so the convenient script ``publish-to-launchpad.sh`` will -be the easiest way to do that. Currently the only supported releases are **trusty** and **xenial**. -So the command used is:: - - publish-to-launchpad.sh sarra-v2.15.12a1 trusty xenial - - -However, the steps below are a summary of what the script does: - -- for each distribution (precise, trusty, etc) update ``debian/changelog`` to reflect the distribution -- build the source package using:: - - debuild -S -uc -us - -- sign the ``.changes`` and ``.dsc`` files:: - - debsign -k <.changes file> - -- upload to launchpad:: - - dput ppa:ssc-hpc-chp-spc/metpx- <.changes file> - -**Note:** The GPG keys associated with the launchpad account must be configured -in order to do the last two steps. - - - -Backporting a Dependency -++++++++++++++++++++++++ - -Example:: - - backportpackage -k -s bionic -d xenial -u ppa:ssc-hpc-chp-spc/ubuntu/metpx-daily librabbitmq - - -Building an RPM -+++++++++++++++ - -This process is currently a bit clumsy, but it can provide usable RPM packages. -Example of creating a multipass image for fedora to build with:: - - fractal% multipass launch -m 8g --name fed34 https://mirror.csclub.uwaterloo.ca/fedora/linux/releases/34/Cloud/x86_64/images/Fedora-Cloud-Base-34-1.2.x86_64.raw.xz - Launched: fed34 - fractal% - -Based on https://www.redhat.com/sysadmin/create-rpm-package ... install build-dependencies:: - - sudo dnf install -y rpmdevtools rpmlint git - git clone -b development https://github.com/MetPX/sarracenia sr3 - cd sr3 - -One can build a very limited sort of rpm package on an rpm based distro by -The names of the package for file magic data (to determin file types) has different names on -ubuntu vs. redhat. The last three lines of **dependencies** in pyproject.toml are about -<<<<<<< HEAD -"python-magic", but on redhat/fedora >= 9, it needs to be "file-magic" instead:: - - # remove last three lines of dependencies in setup.py - - * on redhat <=8: vi setup.py ; python3 setup.py bdist_rpm - - # might work, but might need some removals also. - * on redhat >=9: vi pyproject.toml; python3 -m build - -"python-magic", but on redhat, it needs to be "file-magic" instead:: - - vi pyproject.toml - -using the normal (for Redhat) rpmbuild tool:: - - rpmbuild --build-in-place -bb metpx-sr3.spec - -When doing this on the redhat 8, edit the metpx-sr3.spec and potentially pyproject.toml -to remove the other dependencies because there are no OS packages for: paramiko, -watchdog, xattr, & magic. Eventually, one will have removed enough that the rpm file -will be built. - -One can check if the dependencies are there like so:: - - [ubuntu@fed39 sr3]$ rpm -qR /home/ubuntu/rpmbuild/RPMS/noarch/metpx-sr3-3.00.47-0.fc39.noarch.rpm - - /usr/bin/python3 - python(abi) = 3.12 - python3-appdirs - python3-humanfriendly - python3-humanize - python3-jsonpickle - python3-paramiko - python3-psutil - python3-xattr - python3.12dist(appdirs) - python3.12dist(humanfriendly) - python3.12dist(humanize) - python3.12dist(jsonpickle) - python3.12dist(paramiko) - python3.12dist(psutil) >= 5.3 - python3.12dist(watchdog) - python3.12dist(xattr) - rpmlib(CompressedFileNames) <= 3.0.4-1 - rpmlib(FileDigests) <= 4.6.0-1 - rpmlib(PartialHardlinkSets) <= 4.0.4-1 - rpmlib(PayloadFilesHavePrefix) <= 4.0-1 - rpmlib(PayloadIsZstd) <= 5.4.18-1 - - [ubuntu@fed39 sr3]$ - -You can see all of the prefixed python3 dependencies required, as well as the recommended binary accellerator packages -are listed. Then if you install with dnf install, it will pull them all in. Unfortunately, this method does not allow -the specification of version of the python dependencies which are stripped out. on Fedora 34, this is not a problem, -as all versions are new enough. Such a package should install well. - -After installation, one can supplement, installing missing dependencies using pip (or pip3.) -Can check how much sr3 is working using *sr3 features* and use pip to add more features -after the RPM is installed. - -Certainly a bit clumsy, and not sure if it will work with older versions: -`Help Wanted `_ - - -github ------- - -Click on Releases, Edit the release: - -* should we have release names? -* copy/paste of changes from CHANGES.rst -* copy/paste of Installation bit at the end from a previous release. -* build packages locally or download from other sources. - drag and drop into the release. - -This will give us the ability to have old versions available. -launchpad.net doesn't seem to keep old versions around. - - -Development Environment ------------------------ - - Local Python ~~~~~~~~~~~~ @@ -1812,4 +1350,3 @@ If the dependency is added in a plugin, then there is also a method for that des `Plugin Developer Guide <../Explanation/SarraPluginDev.html#callbacks-that-need-python-modules>` - diff --git a/docs/source/Contribution/Release.rst b/docs/source/Contribution/Release.rst new file mode 100644 index 000000000..e1def4d92 --- /dev/null +++ b/docs/source/Contribution/Release.rst @@ -0,0 +1,606 @@ +============================ + Releasing MetPX-Sarracenia +============================ + +:version: |release| +:date: |today| + + +Pre-Release Overview +-------------------- + +MetPX-Sarracenia is distributed in a few different ways, and each has it's own build process. +Packaged releases are always preferable to one off builds, because they are reproducible. + +To publish a pre-release one needs to: + +- starting with the development branch (for sr3) or v2_dev (for v2.) +- run QA process on all operating systems looking for regressions on older 3.6-based ones. + + - github runs flow tests for ubuntu 20.04 and 22.04, review those results. + - github runs unit tests (only work on newer python versions.), review those results. + - find ubuntu 18.04 server. build local package, run flow tests. + - find redhat 8 server. build package: *python3 setup.py bdist_rpm*, run flow tests + - find redhat 9 server, build package: *python3 -m build --no-isolation*. run flow tests + +- review debian/changelog and update it based on all merges to the branch since previous release. +- Set the pre-release tag. +- commit the above. + +- pypi.org + + - to ensure compatiblity with python3.6, update a python3.6 branch (for redhat 8 and/or ubuntu 18.) + - use the python3.6 branch to release to pypi (because upward compatibility works, but not downward.) + - upload the pre-release so that installation with pip succeeds. + +- launchpad.org: + + * ensure the two branches are ready on github. + * pre-release branch ready. + * pre-release_py36 branch ready. + * update git repository (Import now): https://code.launchpad.net/~ssc-hpc-chp-spc/metpx-sarracenia/+git/trunk + * do: **Import Now** + * run the recipe for old OS (18.04, 20.04) https://code.launchpad.net/~ssc-hpc-chp-spc/+recipe/metpx-sr3-pre-release-old + * do: **Request Build** (on Focal and Bionic ) + * run the recipe for new OS (22.04, 24.04) https://code.launchpad.net/~ssc-hpc-chp-spc/+recipe/metpx-sr3-pre-release + * do: **Request Build** (on Jammy and Noble at least) + +- build redhat packages. + + - find redhat 8 server. build package: python3 setup.py bdist_rpm + - find redhat 9 server, build package: python3 -m build --no-isolation + +- on github: Draft a release. + + - create release notes as prompted. + - copy the installation instructions from a previous release (for mostly ubuntu.) + - attach: + - wheel built on python3.6 on ubuntu 18 (the uploaded to pypi.org) + - windows binary. + - redhat 8 and 9 rpms labelled as such. + +- encourage testing of pre-release, wait some time for blockers, if any. + + +Stable Release Process +---------------------- + +A Stable version is just a pre-release version that has been +re-tagged as stable after some period of waiting for issues +to arise. Since all the testing was done for the pre-release, +the stable release does not require any explicit testing. + +* merge from pre-release to stable:: + + git checkout stable + git merge pre-release + # there will be conflicts here for debian/changelog and sarracenia/_version.py + # for changelog: + # - merge all the rcX changelogs into a single stable one. + # - ensure the version at the top is correct and tagged 'unstable' + # - edit the signature at the bottom for reflect who you are, and current date. + # for sarracenia/_version.py + # - fix it so it shows the correct stable version. + git tag -a v3.xx.yy -m "v3.xx.yy" + git push origin v3.xx.yy + +* merge from pre-release_py36 to stable_py36:: + + git checkout stable_py36 + git merge pre-release_py36 + # same editing required as above. + git tag -a o3.xx.yy -m "o3.xx.yy" + git push origin v3.xx.yy + +* go on Launchpad, + + * stable branch ready. + * stable_py36 branch ready. + * https://code.launchpad.net/~ssc-hpc-chp-spc/metpx-sarracenia/+git/trunk + * do: **Import Now** + * https://code.launchpad.net/~ssc-hpc-chp-spc/+recipe/metpx-sr3-old + * do: **Request Build** (on Focal and Bionic ) + * https://code.launchpad.net/~ssc-hpc-chp-spc/+recipe/metpx-sr3 + * do: **Request Build** (on Jammy and Noble at least) + +* go on ubuntu 18.04, build bdist_wheel:: + + git checkout stable_py36 + python3 setup.py bdist_wheel + +note that *pip3 install wheel* is needed, because the one from +ubuntu 18 is not compatible with the current pypi.org. + +* go on redhat 8, build rpm:: + + git checkout stable_py36 + python3 setup.py bdist_rpm + +* go on redhat 9, build rpm:: + + git checkout stable_py36 + rpmbuild --build-in-place -bb metpx-sr3.spec + + +* On github.com, create release. + + * copy/paste install procedure from a previous release, adjust + * attach wheel build on ubuntu 18. + * attach redhat 8 rpm + * attach redhat 9 rpm + * attach windows exe + + +Details +------- + + +Quality Assurance +~~~~~~~~~~~~~~~~~ + +The Quality Assurance (QA) process, occurs mainly on the development branch. +prior to accepting a release, and barring known exceptions, + +* QA tests automatically triggerred by pushes to the development branch should all pass. + (All related github actions.) + tests: static, no_mirror, flakey_broker, restart_server, dynamic_flow are included in "flow.yml" + +* build an ubuntu 18.04 vm and run the flow tests there to ensure that it works. + (installation method: cloning from development on github.) + tests: static, no_mirror, flakey_broker, restart_server, dynamic_flow + +* build a redhat 8 vm and run the flow test there to ensure that it works. + (installation method: cloning from development on github.) + tests: static, no_mirror, flakey_broker, restart_server, dynamic_flow + +* build a redhat 9 vm and run the flow test there to ensure that it works. + +* build a windows executable... test? + +For extensive discussion see: https://github.com/MetPX/sarracenia/issues/139 + +Once the above are done, the pre-release process can proceed. + + +Versioning Scheme +~~~~~~~~~~~~~~~~~ + +Each release will be versioned as ``.. `` + +It is difficult to reconcile debian and python versioning conventions. +We use rcX for pre-releases which work in both contexts. + +Where: + +- **Version** is the application version. Currently, 2 and 3 exist. +- **YY** is the last two digits of the year of the initial release in the series. +- **MM** is a TWO digit month number i.e. for April: 04. +- **segment** is what would be used within a series. + from pep0440: + X.YrcN # Release Candidate + X.Y # Final release + X.ypN #ack! patched release. + +Currently, 3.00 is still stabilizing, so the year/month convention is not being applied. +Releases are currently 3.00.iircj +where: + + * ii -- incremental number of pre-releases of 3.00 + + * j -- beta increment. + +The first alpha release of v2 from January 2016 would be versioned +as ``metpx-sarracenia-2.16.01a01``. A sample v3 is v3.00.52rc2. At some point 3.00 +will be complete & solid enough that the we will resume the year/month convention. + +Final versions have no suffix and are considered stable and supported. +Stable should receive bug-fixes if necessary from time to time. + +.. Note:: If you change default settings for exchanges / queues as + part of a new version, keep in mind that all components have to use + the same settings or the bind will fail, and they will not be able + to connect. If a new version declares different queue or exchange + settings, then the simplest means of upgrading (preserving data) is to + drain the queues prior to upgrading, for example by + setting, the access to the resource will not be granted by the server. + (??? perhaps there is a way to get access to a resource as is... no declare) + (??? should be investigated) + + Changing the default requires the removal and recreation of the resource. + This has a major impact on processes... + + +Set the Version +~~~~~~~~~~~~~~~ + +This is done to *start* development on a version. It should be done on development +after every release. + +* git checkout development +* Edit ``sarracenia/_version.py`` manually and set the version number. +* Edit CHANGES.rst to add a section for the version. +* run dch to start the changelog for the current version. + * change *unstable* to *UNRELEASED* (maybe done automatically by dch.) +* git commit -a +* git push + + +Git Branches for Pre-release +~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Prior to releasing, ensure that all QA tests in the section above are passed. +When development for a version is complete. The following should occur: + +A tag should be created to identify the end of the cycle:: + + git checkout development + git tag -a v3.16.01rc1 -m "release 3.16.01rc1" + git push + git push origin v3.16.01rc1 + +Once the tag is in the development branch, promote it to stable:: + + git checkout pre-release + git merge development + git push + +Once stable is updated on github, the docker images will be automatically upgraded, but +we then need to update the various distribution methods: `PyPI`_, and `Launchpad`_ + +Once package generation is complete, one should `Set the Version`_ +in development to the next logical increment to ensure no further development +occurs that is identified as the released version. + + +Build Python3.6 Compatbile Branch +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Canonical, the company behind Ubuntu, provides Launchpad as a means of enabling third parties to build +packages for their operating system releases. It turns out that the newer OS versions have dependencies +that are not available on the old ones. So the development branch is configured to build on newer +releases, but an a separate branch must be created when creating releases for ubuntu bionic (18.04) and +focal (20.04.) The same branch can be used to build on redhat 8 (another distro that uses python 3.6) + +Post python 3.7.?, the installatiion method changes from the obsolete setup.py to use pyproject.toml, +and the *hatch* python tools. Prior to that version, hatchling is not supported, so setup.py must be used. +However the presence of pyproject.toml fools the setup.py into thinking it can install it. To +get a correct installation one must: + +* remove pyproject.toml (because setup.py gets confused.) + +* remove "pybuild-plugin-prproject" dep from debuan + +in detail:: + + # on ubuntu 18.04 or redhat 8 (or some other release with python 3.6 ) + + git checkout pre-release + git branch -D pre-release_py36 + git branch stable_py36 + git checkout stable_py36 + vi debian/control + # remove pybuild-plugin-pyproject from the "Build-Depends" + git rm pyproject.toml + # remove the new-style installer to force use of setup.py + git commit -a -m "adjust for older os" + +There might be a "--force" required at some point. Perhaps something along the lines of:: + + git push origin stable_py36 --force + +Then proceed with Launchpad instructions. + + +PyPi +~~~~ + +Because python packages are upward compatible, but not downward, build them on ubuntu 18.04 +(oldest supported python & OS version.) in order for pip installs to work on the widest number +of systems. + +for local installation on a computer with a python 3.6 for testing and development:: + + python3 setup.py bdist_wheel + +or... on newer systems, using build instead:: + + python3 -m build --no-isolation + +Pypi does not distinguish between older and newer python releases. There is only one package +version for all supported versions. When uploading from a new OS, the versions in use on the +OS are inferred to be the minimum, and so installation on older operating systems may be blocked +by generated dependencies on overly modern versions. + +So when uploading to pypi, always do so from the oldest operating system where it needs to work. +upward compatibility is more likely than downward. + +Pypi Credentials go in ~/.pypirc. Sample Content:: + + [pypi] + username: SupercomputingGCCA + password: + +Assuming pypi upload credentials are in place, uploading a new release used to be a one liner:: + + python3 setup.py bdist_wheel upload + +on older systems, or on (python >= 3.7) newer ones:: + + twine upload dist/metpx_sarracenia-2.22.6-py3-none-any.whl dist/metpx_sarracenia-2.22.6.tar.gz + +Should always include source (the .tar.gz file) +Note that the CHANGES.rst file is in restructured text and is parsed by pypi.python.org +on upload. + +.. Note:: + + When uploading pre-release packages (alpha,beta, or RC) PYpi does not serve those to users by default. + For seamless upgrade, early testers need to do supply the ``--pre`` switch to pip:: + + pip3 install --upgrade --pre metpx-sarracenia + + On occasion you may wish to install a specific version:: + + pip3 install --upgrade metpx-sarracenia==2.16.03a9 + + command line use of setup.py is deprecated. Replaced by build and twine. + + +Launchpad +--------- + +Generalities about using Launchpad for MetPX-Sarracenia. + +Repositories & Recipes +~~~~~~~~~~~~~~~~~~~~~~ + +For Ubuntu operating systems, the launchpad.net site is the best way to provide packages that are fully integrated +( built against current patch levels of all dependencies (software components that Sarracenia relies +on to provide full functionality.)) Ideally, when running a server, a one should use one of the repositories, +and allow automated patching to upgrade them as needed. + +Before every build of any package, it is important to update the git repo mirror on launchpad. + +* https://code.launchpad.net/~ssc-hpc-chp-spc/metpx-sarracenia/+git/trunk +* do: **Import Now** + +Wait until this completes. + +Repositories: + +* Daily https://launchpad.net/~ssc-hpc-chp-spc/+archive/ubuntu/metpx-daily (living on dev... ) + should, in principle, be always ok, but regressions happen, and not all testing is done prior to every + commit to dev branches. + Recipes: + + * metpx-sr3-daily -- automated daily build of sr3 packages happens from *development* branch. + * sarracenia-daily -- automated daily build of v2 packages happens from *v2_dev* branch + +* Pre-Release https://launchpad.net/~ssc-hpc-chp-spc/+archive/ubuntu/metpx-pre-release (for newest features.) + from *development* branch. Developers manually trigger builds here when it seems appropriate (testing out + code that is ready for release.) + + * metpx-sr3-pre-release -- on demand build sr3 packages from pre-release branch. + * metpx-sr3-pre-release-old -- on demand build sr3 packages from *pre-release_py36* branch. + * metpx-sarracenia-pre-release -- on demand build sr3 packages from *v2_dev* branch. + +* Release https://launchpad.net/~ssc-hpc-chp-spc/+archive/ubuntu/metpx (for maximum stability) + from *v2_stable* branch. After testing in systems subscribed to pre-releases, Developers + merge from v2_dev branch into v2_stable one, and manually trigger a build. + + * metpx-sr3 -- on demand build sr3 packages from *stable* branch. + * metpx-sr3-old -- on demand build sr3 packages from *stable_py36* branch. + * sarracenia-release -- on deman build v2 packages from *v2_stable* branch. + +for more discussion see `Which Version is stable `_ + + + +Automated Build +~~~~~~~~~~~~~~~ + +* Ensure the code mirror is updated by checking the **Import details** by checking `this page for sarracenia `_ +* if the code is out of date, do **Import Now** , and wait a few minutes while it is updated. +* once the repository is upto date, proceed with the build request. +* Go to the `sarracenia release `_ recipe +* Go to the `sr3 release `_ recipe +* Click on the **Request build(s)** button to create a new release +* for Sarrac, follow the procedure `here `_ +* The built packages will be available in the `metpx ppa `_ + + +Daily Builds +~~~~~~~~~~~~ + +Daily builds are configured +using `this recipe for python `_ +and `this recipe for C `_ and +are run once per day when changes to the repository occur. These packages are stored in the `metpx-daily ppa `_. +One can also **Request build(s)** on demand if desired. + + +Manual Process +++++++++++++++ + +The process for manually publishing packages to Launchpad ( https://launchpad.net/~ssc-hpc-chp-spc ) +involves a more complex set of steps, and so the convenient script ``publish-to-launchpad.sh`` will +be the easiest way to do that. Currently the only supported releases are **trusty** and **xenial**. +So the command used is:: + + publish-to-launchpad.sh sarra-v2.15.12a1 trusty xenial + + +However, the steps below are a summary of what the script does: + +- for each distribution (precise, trusty, etc) update ``debian/changelog`` to reflect the distribution +- build the source package using:: + + debuild -S -uc -us + +- sign the ``.changes`` and ``.dsc`` files:: + + debsign -k <.changes file> + +- upload to launchpad:: + + dput ppa:ssc-hpc-chp-spc/metpx- <.changes file> + +**Note:** The GPG keys associated with the launchpad account must be configured +in order to do the last two steps. + + + +Backporting a Dependency +++++++++++++++++++++++++ + +Example:: + + backportpackage -k -s bionic -d xenial -u ppa:ssc-hpc-chp-spc/ubuntu/metpx-daily librabbitmq + + +Building an RPM ++++++++++++++++ + +This process is currently a bit clumsy, but it can provide usable RPM packages. +Example of creating a multipass image for fedora to build with:: + + fractal% multipass launch -m 8g --name fed34 https://mirror.csclub.uwaterloo.ca/fedora/linux/releases/34/Cloud/x86_64/images/Fedora-Cloud-Base-34-1.2.x86_64.raw.xz + Launched: fed34 + fractal% + +Based on https://www.redhat.com/sysadmin/create-rpm-package ... install build-dependencies:: + + sudo dnf install -y rpmdevtools rpmlint git + git clone -b development https://github.com/MetPX/sarracenia sr3 + cd sr3 + +One can build a very limited sort of rpm package on an rpm based distro by +The names of the package for file magic data (to determin file types) has different names on +ubuntu vs. redhat. The last three lines of **dependencies** in pyproject.toml are about +"python-magic", but on redhat/fedora >= 9, it needs to be "file-magic" instead:: + + # remove last three lines of dependencies in setup.py + + * on redhat <=8: vi setup.py ; python3 setup.py bdist_rpm + + # might work, but might need some removals also. + * on redhat >=9: vi pyproject.toml; python3 -m build + +"python-magic", but on redhat, it needs to be "file-magic" instead:: + + vi pyproject.toml + +using the normal (for Redhat) rpmbuild tool:: + + rpmbuild --build-in-place -bb metpx-sr3.spec + +When doing this on the redhat 8, edit the metpx-sr3.spec and potentially pyproject.toml +to remove the other dependencies because there are no OS packages for: paramiko, +watchdog, xattr, & magic. Eventually, one will have removed enough that the rpm file +will be built. + +One can check if the dependencies are there like so:: + + [ubuntu@fed39 sr3]$ rpm -qR /home/ubuntu/rpmbuild/RPMS/noarch/metpx-sr3-3.00.47-0.fc39.noarch.rpm + + /usr/bin/python3 + python(abi) = 3.12 + python3-appdirs + python3-humanfriendly + python3-humanize + python3-jsonpickle + python3-paramiko + python3-psutil + python3-xattr + python3.12dist(appdirs) + python3.12dist(humanfriendly) + python3.12dist(humanize) + python3.12dist(jsonpickle) + python3.12dist(paramiko) + python3.12dist(psutil) >= 5.3 + python3.12dist(watchdog) + python3.12dist(xattr) + rpmlib(CompressedFileNames) <= 3.0.4-1 + rpmlib(FileDigests) <= 4.6.0-1 + rpmlib(PartialHardlinkSets) <= 4.0.4-1 + rpmlib(PayloadFilesHavePrefix) <= 4.0-1 + rpmlib(PayloadIsZstd) <= 5.4.18-1 + + [ubuntu@fed39 sr3]$ + +You can see all of the prefixed python3 dependencies required, as well as the recommended binary accellerator packages +are listed. Then if you install with dnf install, it will pull them all in. Unfortunately, this method does not allow +the specification of version of the python dependencies which are stripped out. on Fedora 34, this is not a problem, +as all versions are new enough. Such a package should install well. + +After installation, one can supplement, installing missing dependencies using pip (or pip3.) +Can check how much sr3 is working using *sr3 features* and use pip to add more features +after the RPM is installed. + + +Building a Windows Installer +---------------------------- + +One can also build a Windows installer with that +`script `_. +It needs to be run from a Linux OS (preferably Ubuntu 18) in the root directory of Sarracenia's git. +find the python version in use:: + + fractal% python -V + Python 3.10.12 + fractal% + +So this is python 3.10. Only a single minor version will have the embedded package needed +by pynsist to build the executable, so look at:: + + https://www.python.org/downloads/windows/ + +Then go look on python.org, for the "right" version (for 3.10, it is 3.10.11 ) +Then, from the shell, run:: + + sudo apt install nsis + pip3 install pynsist wheel + ./generate-win-installer.sh 3.10.11 2>&1 > log.txt + +The final package will be generated into build/nsis directory. + + +github +------ + +* Click on Releases +* Click on tags, pick the tag for the new release vXX.yy.zzrcw +* Click on Pre-Release tag at the bottom if appropriate. +* Click on Generate Release notes... Review. +* copy/paste of Installation bit at the end from a previous release. +* Save as Draft. +* build packages locally or download from other sources. + drag and drop into the release. +* Publish. + +This will give us the ability to have old versions available. +launchpad.net doesn't seem to keep old versions around. + + +Troubleshooting +--------------- + + + +ubuntu 18 +--------- + +trying to upload from ubuntu 18 vm:: + + buntu@canny-tick:~/sr3$ twine upload dist/metpx_sr3-3.0.53rc2-py3-none-any.whl + /usr/lib/python3/dist-packages/requests/__init__.py:80: RequestsDependencyWarning: urllib3 (1.26.18) or chardet (3.0.4) doesn't match a supported version! + RequestsDependencyWarning) + Uploading distributions to https://upload.pypi.org/legacy/ + Uploading metpx_sr3-3.0.53rc2-py3-none-any.whl + 100%|██████████████████████████████████████████████████████████████████████████████████████████████████| 408k/408k [00:00<00:00, 120kB/s] + HTTPError: 400 Client Error: '2.0' is not a valid metadata version. See https://packaging.python.org/specifications/core-metadata for more information. for url: https://upload.pypi.org/legacy/ + ubuntu@canny-tick:~/sr3$ + +I uploaded from redhat8 instead. used pip3 to install twine on redhat, and that was ok. This could be a result +of running the system provided python3-twine on ubuntu. + diff --git a/docs/source/Contribution/index.rst b/docs/source/Contribution/index.rst index 09fc0cb5c..b9250ccf9 100644 --- a/docs/source/Contribution/index.rst +++ b/docs/source/Contribution/index.rst @@ -9,6 +9,7 @@ Contributing AMQPprimer Development Documentation + Release man_page_template.rst mqtt_issues v03 diff --git "a/docs/source/fr/Contribution/D\303\251veloppement.rst" "b/docs/source/fr/Contribution/D\303\251veloppement.rst" index 606e571b8..8293ffdb2 100644 --- "a/docs/source/fr/Contribution/D\303\251veloppement.rst" +++ "b/docs/source/fr/Contribution/D\303\251veloppement.rst" @@ -9,13 +9,13 @@ Guide du développeur MetPX-Sarracenia Outillage --------- -Pour pirater la source Sarracenia, vous avez besoin de: +Pour contribuer à la source Sarracenia, vous avez besoin de: - Un environnement de développement Linux, soit un poste de travail, soit une machine virtuelle quelconque. La configuration à l’aide d’Ubuntu est automatisée, mais un ajustement pour d’autres distributions est possible. Le confort en ligne de commande est un must. -- python3. L’application est développée en Python et dépend des versions python >= 3.5. +- python3. L’application est développée en Python et dépend des versions python >= 3.6. - style: PEP8 sauf que la longueur maximale de la ligne est de 119, appliquée via `pycodestyle `_ @@ -1255,8 +1255,8 @@ La configuration actuelle est qu’il y a quatre branches principales: * les branches issues à fusionner avec stable doivent être appelées issueXXX. -Référentiels ------------- +Dépots de pacquets Ubuntu: Launchpad.net +---------------------------------------- Pour les systèmes d’exploitation Ubuntu, le site launchpad.net est le meilleur moyen de fournir des packages entièrement intégrés (construit par rapport aux niveaux de correctifs actuels de toutes les dépendances @@ -1281,397 +1281,6 @@ Pour plus de détails, voir `Quelle version est stable .. `` - -Où: - -- **version du protocole** est la version du message. Dans les messages de notification Sarra, - ils sont tous préfixés par v02 (pour le moment). -- **YY** est les deux derniers chiffres de l’année de la sortie initiale de la série. -- **MM** est un numéro de mois à DEUX chiffres, c’est-à-dire pour avril: 04. -- **segment** est ce qui serait utilisé dans une série. - De pep0440: - X.YaN # Version Alpha - X.YbN # Version Beta - X.YrcN # Version Candidate - X.Y # Version Final - X.ypostN #ack! Version corrigé. - -Actuellement, 3.00 est toujours stabilisé, de sorte que la convention année/mois n’est pas appliquée. -Les versions sont actuellement 3.00.iibj où: - - * ii -- nombre incrémentiel de versions préliminaires de 3.00 - * j -- incrément bêta. - -À un moment donné, 3.00 sera complet et suffisamment solide pour que nous -reprenions la convention année/mois, espérons-le 3.22. - -Les rejets sont classés comme suit : - -Alpha - Versions instantanées prises directement à partir de development, sans autres garanties qualitatives. - Aucune garantie de fonctionnalité, certains composants peuvent être partiellement mis en œuvre, - certaines bris peuvent survenir. Pas de corrections de bugs, problèmes résolus par la version ultérieure. - Souvent utilisé pour les premiers tests de bout en bout (plutôt que d’installer une forme personnalisé - à partir de l’arborescence sur chaque machine d’essai.) - -Bêta - Fonctionnalité terminée pour une version donnée. Composants dans leur forme finale pour cette version. - La documentation existe dans au moins une langue. - Tous les bogues de blocage de version connus précédemment sont corrigés. - Pas de corrections de bogues, problèmes résolus par la version ultérieure. - -RC - Release Candidate. - Implique qu’il est passé par la version bêta pour identifier et résoudre les problèmes majeurs. - Documentation traduite disponible. - Pas de corrections de bogues, problèmes résolus par la version ultérieure. - -Les versions finales n’ont pas de suffixe et sont considérées comme stables et prises en charge. -Stable devrait recevoir des corrections de bogues si nécessaire de temps en temps. -On peut construire des python Wheels, ou des paquets Debian à des fins de test local -pendant le développement. - -.. Note:: - Si vous modifiez les paramètres par défaut pour les échanges / files d’attente comme - dans le cadre d’une nouvelle version, gardez à l’esprit que tous les composants doivent utiliser - les mêmes paramètres ou la liaison échoueront et ils ne pourront pas - se connecter. Si une nouvelle version déclare des paramètres de fil d’attente ou d’échange différents, - le moyen le plus simple de mettre à niveau (préserver les données) consiste à vider les files d’attente - avant la mise à niveau, par exemple en définissant que l’accès à la ressource ne sera pas accordé par le serveur. - (??? peut-être y a-t-il un moyen d’accéder à une ressource telle quelle... pas de déclaration) - (??? devrait faire l’objet d’une enquête) - - La modification de la valeur par défaut nécessite la suppression et la recréation de la ressource. - Cela a un impact majeur sur les processus... - -Exemple: - -La première version alpha en janvier 2016 serait versionnée comme suit : ``metpx-sarracenia-2.16.01a01`` - - -Définir la version -~~~~~~~~~~~~~~~~~~ - -Ceci est fait pour *démarrer* le développement d’une version. D´habitude, on fais cela immédiatement -après que la version précedente a été relachée. - -* git checkout development -* Modifier ``sarracenia/_version.py`` manuellement et définissez le numéro de version. -* Modifier CHANGES.rst pour ajouter une section pour la version. -* Exécuter dch pour démarrer le journal des modifications de la version actuelle. - - * assurer que UNRELEASED soit l'étiquette de status au lieu de *unstable* (peut-être automatiquement faite par dch) - -* git commit -a -* git push - -Si le développement se poursuit et que le temps passe sans que la libération ne se produise, alors -la version doit être définie à nouveau (ou écrasée). Par exemple, un cycle développement commence -en août, la version principale sera 3.19.08b1... mais si le développement -continue en septembre, il faut utiliser cette procédure pour changer la version à 3.19.09b1. - -Durant le dévéloppement, une paquet devrait être UNRELEASED. Lors de faire un release, -on change l´étiquette pour *unstable*, suivant les habitudes de Debian. En debian: - -* unstable ... un logiciel qui change souvent (des mises-à-jour fréquents) -* testing ... un logiciel dont la version et gélé pour inclusion futur dans une version stable de Debian. -* stable ... un version de logiciel gélé, mise à part des rustines de sécurité. - -Metpx-sr3 est encore trop dynamique pour qualifier comme un logiciel *stable* selon -la conventions de Debian, On n´a pas de version qui reste en utilisation durant plusieurs -années pour l´instant. - - -Releasing -~~~~~~~~~ - -Lorsque le développement d’une version est terminé. Les événements suivants doivent se produire : - -Une balise doit être créée pour identifier la fin du cycle :: - - git checkout development - git tag -a sarra-v3.16.01a01 -m "release 3.16.01a01" - git push - git push origin sarra-v3.16.01a01 - -Une fois que la balise est là dans la branche development, il faut promouvoir sur stable:: - - git checkout stable - git merge development - git push - -Une fois en stable, les images docker seront automatiquement mises à niveau, mais nous devons ensuite mettre à jour -les différentes méthodes de distribution: `PyPI`_, et `Launchpad`_ - -Une fois la génération du package terminée, il faut `Création d'une version`_ -dans development à l’incrément logique suivant pour s’assurer qu’aucun autre développement -identifié comme la version publiée ne se produit. - - -PyPi -~~~~ - -Pypi Credentials vont dans ~/.pypirc. Exemple de contenu:: - - [pypi] - username: SupercomputingGCCA - password: - -En supposant que les informations d’identification de téléchargement pypi sont en place, le téléchargement -d’une nouvelle version était auparavant une ligne unique:: - - python3 setup.py bdist_wheel upload - -sur des systèmes plus anciens ou plus récents:: - - python3 -m build --no-isolation - twine upload dist/metpx_sarracenia-2.22.6-py3-none-any.whl - -Notez que le fichier CHANGES.rst est en texte restructuré et est analysé par pypi.python.org lors du téléchargement. - -.. Note:: - - Lors du téléchargement de packages en version préliminaire (alpha, bêta ou RC), PYpi ne les sert pas aux utilisateurs par défaut. - Pour une mise à niveau transparente, les premiers testeurs doivent fournir le ``--pre`` switch à pip:: - - pip3 install --upgrade --pre metpx-sarracenia - - À l’occasion, vous souhaiterez peut-être installer une version spécifique:: - - pip3 install --upgrade metpx-sarracenia==2.16.03a9 - - L’utilisation de setup.py par ligne de commande est déconseillée. Remplacé par build and twine. - -Launchpad -~~~~~~~~~ - -Build Automatisée -+++++++++++++++++ - -* Assurez-vous que le miroir de code est mis à jour en vérifiant les **Détails de l’importation** en vérifiant - `Cette page pour Sarracenia `_ -* Si le code n’est pas à jour, faites **Import Now** , et attendez quelques minutes pendant qu’il est mis à jour. -* Une fois le référentiel à jour, procédez à la demande de build. -* Accédez à la recette `sarracenia release `_ -* Accédez à la recette `sr3 release `_ -* Cliquez sur le bouton **Request Build(s)** pour créer une nouvelle version. -* pour Sarrac, suivez la procédure `here `_ -* Les packages construits seront disponibles dans le - `metpx ppa `_ - -Ubuntu 18.04 -++++++++++++ - -Pour ubuntu 18.04 (bionique), il y a quelques problèmes. La recette s’appelle: metpx-sr3-daily-bionic, et il -prend la source à partir d’une branche différente : *v03_launchpad*. Pour chaque version, cette branche -doit être rebasée à partir de *development* - -* git checkout v03_launchpad -* git rebase -i development -* git push -* import source -* Request build from *metpx-sr3-daily-bionic* Recipe. - -En quoi cette branche *v03_launchpad* est-elle différente ? Elle: - -* Supprime la dépendance sur python3-paho-mqtt car la version dans le *repository* d´ubuntu est trop ancienne. -* Suppression de la dépendance sur python3-dateparser, car ce paquet n’est pas disponible dans le *repository* d´ubuntu. -* remplacer la cible de test dans debian/rules, parce que tester sans les dépendances échoue :: - - override_dh_auto_test: - echo "disable on 18.04... some deps must come from pip" - -The missing dependencies should be installed with pip3. - - - -Création d’un programme d’installation Windows -++++++++++++++++++++++++++++++++++++++++++++++ - -On peut également construire un programme d’installation Windows avec cela -`script `_. -Il doit être exécuté à partir d’un système d’exploitation Linux (de préférence Ubuntu 18) -dans le répertoire racine de git de Sarracenia. - -déterminer la version de python:: - - fractal% python -V - Python 3.10.12 - fractal% - - -C'est donc python 3.10. Une seule version mineure aura le package intégré nécessaire -par pynsist pour construire l'exécutable. On valide chez:: - - https://www.python.org/downloads/windows/ - -afin to confirmer que la version avec un binaire *embedded* pour 3.10 et le 3.10.11 -Ensuite, à partir du shell, exécutez :: - - sudo apt install nsis - pip3 install pynsist wheel - ./generate-win-installer.sh 3.10.11 2>&1 > log.txt - -Le paquet final doit être placé dans le répertoire build/nsis. - - -Builds quotidiennes -+++++++++++++++++++ - -Les builds quotidiennes sont configurées à l’aide de -`cette recette Python `_ -et `cette recette pour C `_ et -sont exécutés une fois par jour lorsque des modifications sont apportées au référentiel.These packages are stored in the -Ces packages sont stockés dans le `metpx-daily ppa `_. -On peut également **Request Build(s)** à la demande si vous le souhaitez. - -Processus manuel -++++++++++++++++ - -Le processus de publication manuelle des packages sur Launchpad ( https://launchpad.net/~ssc-hpc-chp-spc ) -implique un ensemble d’étapes plus complexes, et donc le script pratique ``publish-to-launchpad.sh`` sera -le moyen le plus simple de le faire. Actuellement, les seules versions prises en charge sont **trusty** et **xenial**. -La commande utilisée est donc la suivante :: - - publish-to-launchpad.sh sarra-v2.15.12a1 trusty xenial - - -Toutefois, les étapes ci-dessous sont un résumé de ce que fait le script : - -- pour chaque distribution (precise, trusty, etc) mettez à jour ``debian/changelog`` pour refléter la distribution -- Générez le package source en utilisant :: - - debuild -S -uc -us - -- signez les fichiers ``.changes`` et ``.dsc``:: - - debsign -k <.changes file> - -- Télécharger vers Launchpad:: - - dput ppa:ssc-hpc-chp-spc/metpx- <.changes file> - -**Remarque :** Les clés GPG associées au compte du tableau de bord doivent être configurées -afin de faire les deux dernières étapes. - -Rétroportage d’une dépendance -+++++++++++++++++++++++++++++ - -Exemple:: - - backportpackage -k -s bionic -d xenial -u ppa:ssc-hpc-chp-spc/ubuntu/metpx-daily librabbitmq - - -Création d’un RPM -+++++++++++++++++ - -Ce processus est actuellement un peu maladroit, mais il peut fournir des packages RPM utilisables. -Exemple de création d’une image multipasse pour fedora à construire avec:: - - fractal% multipass launch -m 8g --name fed34 https://mirror.csclub.uwaterloo.ca/fedora/linux/releases/34/Cloud/x86_64/images/Fedora-Cloud-Base-34-1.2.x86_64.raw.xz - Launched: fed34 - fractal% - -Basé sur https://www.redhat.com/sysadmin/create-rpm-package ... installer les dépendances de build:: - - sudo dnf install -y rpmdevtools rpmlint git - git clone -b development https://github.com/MetPX/sarracenia sr3 - cd sr3 - -Les noms du package pour les données magiques de fichiers (pour déterminer les types de fichiers) ont des noms différents sur -Ubuntu contre RedHat. Les trois dernières lignes de **dépendances** dans pyproject.toml concernent -"python-magic", mais sur Redhat, il doit plutôt être "file-magic" :: - - vi pyproject.toml - -On peut construire paquet rpm sur une distribution de Linux approprié, avec la commande *rpmbuild*:: - - rpmbuild --build-in-place -bb metpx-sr3.spec - -Cela marche tel quel sur fedora 39, mais ca se peut qu´il faut editer metpx-sr3.spec afin d´enlever -des paquets listé comme *dependencies*, faute de disponibilité en format RPM dans les anciennes -versions de Redhat. Eventuellement, on aura enlevé assez de dépendences pour que le .rpm se construit. - -On peut vérifier si les dépendances sont là comme ça:: - - [ubuntu@fed39 sr3]$ rpm -qR /home/ubuntu/rpmbuild/RPMS/noarch/metpx-sr3-3.00.47-0.fc39.noarch.rpm - - /usr/bin/python3 - python(abi) = 3.12 - python3-appdirs - python3-humanfriendly - python3-humanize - python3-jsonpickle - python3-paramiko - python3-psutil - python3-xattr - python3.12dist(appdirs) - python3.12dist(humanfriendly) - python3.12dist(humanize) - python3.12dist(jsonpickle) - python3.12dist(paramiko) - python3.12dist(psutil) >= 5.3 - python3.12dist(watchdog) - python3.12dist(xattr) - rpmlib(CompressedFileNames) <= 3.0.4-1 - rpmlib(FileDigests) <= 4.6.0-1 - rpmlib(PartialHardlinkSets) <= 4.0.4-1 - rpmlib(PayloadFilesHavePrefix) <= 4.0-1 - rpmlib(PayloadIsZstd) <= 5.4.18-1 - - [ubuntu@fed39 sr3]$ - - -Vous pouvez voir toutes les dépendances python3 préfixées requises, ainsi que les paquets d’accellerator -binaires recommandés sont répertoriés. Ensuite, si vous installez avec dnf install, il les attirera tous. -Malheureusement, cette méthode ne permet pas de spécifier la version des dépendances python qui sont -supprimées. sur Fedora 34, ce n’est pas un problème, car toutes les versions sont assez récentes. -Un tel paquet devrait bien s’installer. - - -Un peu inélégant, et pas sûr que cela fonctionnera avec les anciennes versions:: -`Aide recherchée `_ - - -github ------- - -Cliquez sur Releases, modifiez la release : - -* Devrions-nous avoir des noms de sortie? -* copier/coller des modifications de CHANGES.rst -* copier/coller le bit d’installation à la fin d’une version précédente. -* Construire des paquets localement ou télécharger à partir d’autres sources. - Glissez-déposez dans la version. - -Cela nous donnera la possibilité d’avoir d’anciennes versions disponibles. -launchpad.net ne semble pas garder les anciennes versions. - -Environnement de développement ------------------------------- Local Python @@ -1709,21 +1318,9 @@ journal local est utilisé. Par exemple, sr_shovel n’émet aucun message sr_r donnée n’est transférée, seulement des messages. -Adding a New Dependency ------------------------ +Àjout d´un Dépendence +--------------------- -Dependency Management is a complicated topic, because python has many different installation methods into disparate environments, and Sarracenia is multi-platform. Standard python practice for dependencies is to make -them *required* by listing them in requirements.txt or setup.py, and require all users to install them. -In most python applications, if a dependency is missing, it just crashes with a import failure message -of some kind. - -In Sr3, we have found that there are many different environments being deployed into where satisfying -dependencies can be more trouble than they are worth, so each of the dependencies in setup.py are also -dealt with in sarracenia/featuredetection, and the feature detection code allows the application to -keep working, just without the functionality provided by the missing module. This is called *degradation* -or *degraded mode*. The idea being to help the user do as much as they can, in the environment they have, -while telling them what is missing, and what would ideally be added. - La gestion des dépendances est un sujet compliqué, car python a de nombreuses méthodes d'installation différentes dans des environnements disparates, et Sarracenia est multi-plateforme. La pratique standard de python pour les dépendances consiste à faire les *nécessaires* en les listant dans requirements.txt diff --git a/docs/source/fr/Contribution/Publication.rst b/docs/source/fr/Contribution/Publication.rst new file mode 100644 index 000000000..cc0876dbc --- /dev/null +++ b/docs/source/fr/Contribution/Publication.rst @@ -0,0 +1,531 @@ +======================================= +Publier une Version de MetPX-Sarracenia +======================================= + +:version: |release| +:date: |today| + + +Processus de Pre-Publication +---------------------------- + +Pour publier une nouvelle version, on commence avec une *pre-release*, et, après une période +de vérification, la publication d´une version stable. MetPX-Sarracenia est distribué de +différentes manières, et chacune a son propre processus de construction. Les versions +packagées sont toujours préférables aux versions uniques, car elles sont reproductibles. + +Pour publier une pré-version, il faut : + +- en commençant par la branche développement (pour sr3) ou v2_dev (pour v2.) +- exécuter le processus d'assurance qualité sur tous les systèmes d'exploitation à la recherche de régressions sur les anciens systèmes basés sur 3.6. + + - github exécute des tests de flux pour Ubuntu 20.04 et 22.04, examinez ces résultats. + - github exécute des tests unitaires (ne fonctionne que sur les versions les plus récentes de Python.), examinez ces résultats. + - trouver le serveur Ubuntu 18.04. créez un package local, exécutez des tests de flux. + - trouver le serveur Redhat 8. package de construction : *python3 setup.py bdist_rpm*, exécutez des tests de flux + - recherchez le serveur Redhat 9, construisez le package : *python3 -m build --no-isolation*. exécuter des tests de flux + +- examinez Debian/changelog et mettez-le à jour en fonction de toutes les fusions (merge) vers la branche depuis la version précédente. +- Définissez la balise (tag) de pré-version. +- commettre ce qui précède. + +- pypi.org + + - pour assurer la compatibilité avec python3.6, mettre à jour une branche python3.6 (pour redhat 8 et/ou ubuntu 18.) + - utilisez la branche python3.6 pour publier sur pypi (car la compatibilité ascendante fonctionne, mais pas vers le bas.) + - téléchargez la pré-version pour que l'installation avec pip réussisse. + + +- launchpad.org : + + * assurez-vous que les deux branches sont prêtes sur github. + * Branche préliminaire prête. + * Branche pre-release_py36 prête. + * mettre à jour le référentiel git (importer maintenant) : https://code.launchpad.net/~ssc-hpc-chp-spc/metpx-sarracenia/+git/trunk + * faire : **Import Now** + * exécutez la recette pour l'ancien système d'exploitation (18.04, 20.04) https://code.launchpad.net/~ssc-hpc-chp-spc/+recipe/metpx-sr3-pre-release-old + * faire : **Request Build** (sur Focal et Bionic) + * exécutez la recette pour le nouveau système d'exploitation (22.04, 24.04) https://code.launchpad.net/~ssc-hpc-chp-spc/+recipe/metpx-sr3-pre-release + * faire : **Request Build** (au moins sur Jammy and Noble) + +- créer des packages RedHat. + + - trouver le serveur Redhat 8. package de construction : python3 setup.py bdist_rpm + - trouver le serveur Redhat 9, package de construction : python3 -m build --no-isolation + +- sur github : rédiger une version. + + - créez des notes de version lorsque vous y êtes invité. + - copiez les instructions d'installation d'une version précédente (principalement pour Ubuntu.) + - attacher: + - roue construite sur python3.6 sur Ubuntu 18 (téléchargée sur pypi.org) + - Windows binaire. + - des redhat 8 et 9 tours étiquetés comme tels. + +- encourager les tests de pré-version, attendre un certain temps pour les bloqueurs, le cas échéant. + + +Processus de Publication de Version Stable +------------------------------------------ + +Une version stable est simplement une version préliminaire qui a été +re-étiqueté comme stable après une certaine période d'attente pour les problèmes +se lever. Puisque tous les tests ont été effectués pour la pré-version, +la version stable ne nécessite aucun test explicite. + +* fusionner de la pre-release à la version stable : : + + git checkout stable + git merge pre-release + # il y aura des conlits à résoudre pour les fichier: debian/changelog and sarracenia/_version.py + # Pour le changelog: + # - joindre les changements pour tous les rcX dans une seule block pour la version stable. + # - assurer que la version en haut du block est juste et étiqueté: *unstable* + # - editer la signature pour avoir le bon responsable et date pour le relache. + # pour sarracenia/_version.py + # - ajuster pour qu´il contienne la bonne version. + git tag -a v3.xx.yy -m "v3.xx.yy" + git push origin v3.xx.yy + +* fusionner de la pre-release_py36 à stable_36:: + + git checkout stable_py36 + git merge pre-release_py36 + # les mêmes ajustements que pour la version stable. + git tag -a o3.xx.yy -m "o3.xx.yy" + git push origin v3.xx.yy + +* sur Launchpad.net + + * Branche stable prête. + * Branche stable_py36 prête. + * https://code.launchpad.net/~ssc-hpc-chp-spc/metpx-sarracenia/+git/trunk + * faire : **Import Now** + * https://code.launchpad.net/~ssc-hpc-chp-spc/+recipe/metpx-sr3-old + * faire : **Request Build** (sur Focal et Bionic) + * https://code.launchpad.net/~ssc-hpc-chp-spc/+recipe/metpx-sr3 + * faire : **Request Build** (au moins sur Jammy and Noble) + +* sur re + * go on redhat 8, build rpm:: + + git checkout stable_py36 + python3 setup.py bdist_rpm + +* go on redhat 9, build rpm:: + + git checkout stable_py36 + rpmbuild --build-in-place -bb metpx-sr3.spec + + +* Sur github.com, *Create a Release from a tag* + + * copie/coller procédure d´installation d´un vieux relâche. + * télécharger en pièce-jointe: un .whl + * télécharger en pièce-jointe: redhat 8 rpm + * télécharger en pièce-jointe: redhat 9 rpm + * télécharger en pièce-jointe: windows.exe + + +Detailles +--------- + + +Assurance de Qualité +~~~~~~~~~~~~~~~~~~~~ + +Le processus d'assurance qualité (AQ) se déroule principalement dans la branche développement. +avant d'accepter une contribution, et sauf exceptions connues, + +* Les tests d'assurance qualité déclenchés automatiquement par les demandes de pull vers + la branche de développement devraient tous réussir. + (Toutes les actions github associées.) + tests : static, no_mirror, flakey_broker, restart_server,dynamic_flow sont inclus dans "flow.yml" + +* Créez une machine virtuelle Ubuntu 18.04 et exécutez les tests de flux pour vous assurer qu'elle fonctionne. + (méthode d'installation : clonage depuis le développement sur github.) + tests : statique, no_mirror, flakey_broker, restart_server, Dynamic_flow + +* Créez une machine virtuelle Redhat 8 et exécutez le test de flux pour vous assurer qu'il fonctionne. + (méthode d'installation : clonage depuis le développement sur github.) + tests : statique, no_mirror, flakey_broker, restart_server, Dynamic_flow + +* Créez une machine virtuelle Redhat 9 et exécutez le test de flux pour vous assurer qu'il fonctionne. + +* construire un exécutable Windows... tester ? + +Pour une discussion approfondie, voir : https://github.com/MetPX/sarracenia/issues/139 + +Une fois les étapes ci-dessus terminées, le processus de pré-version peut continuer. + + +Schéma de contrôle de version +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Chaque version sera versionnée en tant que ``.. `` + +Où: + +- **version du protocole** est la version du message. Dans les messages de notification Sarra, + ils sont tous préfixés par v02 (pour le moment). +- **YY** est les deux derniers chiffres de l’année de la sortie initiale de la série. +- **MM** est un numéro de mois à DEUX chiffres, c’est-à-dire pour avril: 04. +- **segment** est ce qui serait utilisé dans une série. + De pep0440: + X.YaN # Version Alpha + X.YbN # Version Beta + X.YrcN # Version Candidate + X.Y # Version Final + X.ypN #ack! Version corrigé. + +Actuellement, 3.00 est toujours stabilisé, de sorte que la convention année/mois n’est pas appliquée. +Les versions sont actuellement 3.00.iibj où: + + * ii -- nombre incrémentiel de versions préliminaires de 3.00 + * j -- incrément bêta. + +À un moment donné, 3.00 sera complet et suffisamment solide pour que nous +reprenions la convention année/mois, espérons-le 3.24. + +Les versions finales n'ont pas de suffixe et sont considérées comme stables. +Stable devrait recevoir des corrections de bugs si nécessaire de temps en temps. + +.. Remarque : Si vous modifiez les paramètres par défaut pour les échanges/files d'attente comme + partie d'une nouvelle version, gardez à l'esprit que tous les composants doivent utiliser + les mêmes paramètres ou la liaison échoueront et ils ne pourront pas + se connecter. Si une nouvelle version déclare une file d'attente ou un échange différent + paramètres, le moyen le plus simple de mise à niveau (en préservant les données) est de + vider les files d'attente avant la mise à niveau, par exemple en + paramètre, l’accès à la ressource ne sera pas accordé par le serveur. + (??? il existe peut-être un moyen d'accéder à une ressource telle quelle... pas de déclaration) + (??? devrait faire l'objet d'une enquête) + + La modification de la valeur par défaut nécessite la suppression et la recréation de la ressource. + Cela a un impact majeur sur les processus... + + +Définir la version +~~~~~~~~~~~~~~~~~~ + +Ceci est fait pour *démarrer* le développement d’une version. D´habitude, on fais cela immédiatement +après que la version précedente a été relachée. + +* git checkout development +* Modifier ``sarracenia/_version.py`` manuellement et définissez le numéro de version. +* Modifier CHANGES.rst pour ajouter une section pour la version. +* Exécuter dch pour démarrer le journal des modifications de la version actuelle. + + * assurer que UNRELEASED soit l'étiquette de status au lieu de *unstable* (peut-être automatiquement faite par dch) + +* git commit -a +* git push + + +Branches Git pour la pré-publication +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Avant la publication, assurez-vous que tous les tests d'assurance qualité de la section ci-dessus ont été réussis. +Lorsque le développement d’une version est terminé. Les événements suivants devraient se produire : + +Un tag doit être créé pour identifier la fin du cycle :: + + git checkout development + git tag -a v3.16.01rc1 -m "release 3.16.01rc1" + git push + git push origin v3.16.01rc1 + +Une fois la balise (tag) dans la branche de développement, promouvez-la en stable :: + + git checkout pre-release + git merge development + git push + + +Une fois *stable* est mis à jour sur github, les images du docker seront automatiquement mises à jour, mais +il faut ensuite mettre à jour les différentes méthodes de distribution : `PyPI`_, et `Launchpad`_ + +Une fois la génération du package terminée, il faut « Définir la version »_ +en développement jusqu'au prochain incrément logique pour garantir qu'il n'y ait aucun développement ultérieur +se produit et est identifié comme la version publiée. + + + + +Configurer une branche compatible Python3.6 +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Canonical, la société derrière Ubuntu, fournit Launchpad pour permettre à des tiers de créer des applications. +packages pour leurs versions de système d’exploitation. Il s'avère que les versions les plus récentes du système d'exploitation ont des dépendances +qui ne sont pas disponibles sur les anciens. La branche de développement est donc configurée pour s'appuyer sur des versions plus récentes. +versions, mais une branche distincte doit être créée lors de la création de versions pour Ubuntu Bionic (18.04) et +focal (20.04.) La même branche peut être utilisée pour construire sur Redhat 8 (une autre distribution qui utilise Python 3.6) + +Après Python 3.7.?, la méthode d'installation passe du setup.py obsolète à l'utilisation de pyproject.toml, +et les outils python *hatch*. Avant cette version, Hatchling n'est pas pris en charge, donc setup.py doit être utilisé. +Cependant, la présence de pyproject.toml trompe setup.py en lui faisant croire qu'il peut l'installer. À +pour obtenir une installation correcte il faut : + +* supprimez pyproject.toml (car setup.py est confus.) + +* supprimer le dépôt "pybuild-plugin-prproject" de debuan + +en détail:: + + # on ubuntu 18.04 or redhat 8 (or some other release with python 3.6 ) + + git checkout pre-release + git branch -D pre-release_py36 + git branch stable_py36 + git checkout stable_py36 + vi debian/control + # remove pybuild-plugin-pyproject from the "Build-Depends" + git rm pyproject.toml + # remove the new-style installer to force use of setup.py + git commit -a -m "adjust for older os" + +Ca se peut qu´une *--force* soit requis à un moment donné. e.g.:: + + git push origin stable_py36 --force + +Une fois la branche mise à jour, procedez aux instructions de Launchpad. + + +PyPi +~~~~ + +Parce ce que les pacquets Python sont compatibles vers le haut, mais pas vers le bas, il faut +les créer sur Ubuntu 18.04 (la plus ancienne version de Python et du système d'exploitation +en utilisation.) afin que les installations pip fonctionnent sur la plus grande varieté +de systèmes. + +En supposant que les informations d’identification de téléchargement pypi sont en place, le téléchargement +d’une nouvelle version était auparavant une ligne unique:: + + python3 setup.py bdist_wheel upload + +sur des systèmes plus anciens ou plus récents:: + + python3 -m build --no-isolation + twine upload dist/metpx_sarracenia-2.22.6-py3-none-any.whl + +Notez que le fichier CHANGES.rst est en texte restructuré et est analysé par pypi.python.org lors du téléchargement. + +.. Note:: + + Lors du téléchargement de packages en version préliminaire (alpha, bêta ou RC), PYpi ne les sert pas aux utilisateurs par défaut. + Pour une mise à niveau transparente, les premiers testeurs doivent fournir le ``--pre`` switch à pip:: + + pip3 install --upgrade --pre metpx-sarracenia + + À l’occasion, vous souhaiterez peut-être installer une version spécifique:: + + pip3 install --upgrade metpx-sarracenia==2.16.03a9 + + L’utilisation de setup.py par ligne de commande est déconseillée. Remplacé par build and twine. + + + +Launchpad.net +------------- + +Généralités sur l'utilisation de Launchpad.net (site pour génerer les paquets pour Ubuntu) pour MetPX-Sarracenia. + +Dépôts et recettes +~~~~~~~~~~~~~~~~~~ + +Pour les systèmes d'exploitation Ubuntu, le site launchpad.net est le meilleur moyen de fournir +des pacquets entièrement intégrés (construit avec les niveaux de correctifs actuels de toutes +les dépendances (composants logiciels sur lesquels Sarracenia s'appuie) pour fournir toutes les +fonctionnalités.)) Idéalement, lors de utilisation d'un serveur, celui-ci devrait utiliser +l'un des Dépôts, et installer les correctifs automatisés pour les mettre à niveau si nécessaire. + +Avant chaque build d'un package, il est important de mettre à jour le miroir du dépôt git sur le tableau de bord. + +* https://code.launchpad.net/~ssc-hpc-chp-spc/metpx-sarracenia/+git/trunk +* do: **Import Now** + +Attendez que ca soit fini (quelques minutes.) + +Dépôts : + +* Quotidien https://launchpad.net/~ssc-hpc-chp-spc/+archive/ubuntu/metpx-daily (vivant sur dev... ) + devrait, en principe, toujours être correct, mais des régressions se produisent et tous les + tests ne sont pas effectués avant chaque contribution dans les branches de développement. + Recettes: + + * metpx-sr3-daily -- la construction quotidienne automatisée des packages sr3 s'effectue à partir de la branche *development*. + * sarracenia-daily -- la construction quotidienne automatisée des packages v2 s'effectue à partir de la branche *v2_dev* + +* Pré-Release https://launchpad.net/~ssc-hpc-chp-spc/+archive/ubuntu/metpx-pre-release (pour les fonctionnalités les plus récentes.) + de la branche *développement*. Les développeurs déclenchent manuellement les builds ici lorsque cela semble approprié (tests + code prêt à être publié.) + + * metpx-sr3-pre-release -- créez à la demande des packages sr3 à partir de la branche de *pre_release*. + * metpx-sr3-pre-release-old -- build à la demande des packages sr3 à partir de la branche *pre-release_py36*. + * metpx-sarracenia-pre-release -- build à la demande des packages sr3 à partir de la branche *v2_dev*. + +* Release https://launchpad.net/~ssc-hpc-chp-spc/+archive/ubuntu/metpx (pour une stabilité maximale) + de la branche *v2_stable*. Après avoir testé sur des systèmes abonnés aux pré-versions, les développeurs + fusionner de la branche v2_dev dans celle de v2_stable et déclencher manuellement une construction. + + * metpx-sr3 -- à la demande, créez des packages sr3 à partir de la branche *stable*. + * metpx-sr3-old -- créez à la demande des packages sr3 à partir de la branche *stable_py36*. + * sarracenia-release -- sur deman, construisez les packages v2 à partir de la branche *v2_stable*. + + + +Launchpad +~~~~~~~~~ + +Build Automatisée ++++++++++++++++++ + +* Assurez-vous que le miroir de code est mis à jour en vérifiant les **Détails de l’importation** en vérifiant + `Cette page pour Sarracenia `_ +* Si le code n’est pas à jour, faites **Import Now** , et attendez quelques minutes pendant qu’il est mis à jour. +* Une fois le référentiel à jour, procédez à la demande de build. +* Accédez à la recette `sarracenia release `_ +* Accédez à la recette `sr3 release `_ +* Cliquez sur le bouton **Request Build(s)** pour créer une nouvelle version. +* pour Sarrac, suivez la procédure `here `_ +* Les packages construits seront disponibles dans le + `metpx ppa `_ + + +Builds quotidiennes ++++++++++++++++++++ + +Les builds quotidiennes sont configurées à l’aide de +`cette recette Python `_ +et `cette recette pour C `_ et +sont exécutés une fois par jour lorsque des modifications sont apportées au référentiel.These packages are stored in the +Ces packages sont stockés dans le `metpx-daily ppa `_. +On peut également **Request Build(s)** à la demande si vous le souhaitez. + + +Processus manuel +++++++++++++++++ + +Le processus de publication manuelle des packages sur Launchpad ( https://launchpad.net/~ssc-hpc-chp-spc ) +implique un ensemble d’étapes plus complexes, et donc le script pratique ``publish-to-launchpad.sh`` sera +le moyen le plus simple de le faire. Actuellement, les seules versions prises en charge sont **trusty** et **xenial**. +La commande utilisée est donc la suivante :: + + publish-to-launchpad.sh sarra-v2.15.12a1 trusty xenial + + +Toutefois, les étapes ci-dessous sont un résumé de ce que fait le script : + +- pour chaque distribution (precise, trusty, etc) mettez à jour ``debian/changelog`` pour refléter la distribution +- Générez le package source en utilisant :: + + debuild -S -uc -us + +- signez les fichiers ``.changes`` et ``.dsc``:: + + debsign -k <.changes file> + +- Télécharger vers Launchpad:: + + dput ppa:ssc-hpc-chp-spc/metpx- <.changes file> + +**Remarque :** Les clés GPG associées au compte du tableau de bord doivent être configurées +afin de faire les deux dernières étapes. + + + +Rétroportage d’une dépendance ++++++++++++++++++++++++++++++ + +Exemple:: + + backportpackage -k -s bionic -d xenial -u ppa:ssc-hpc-chp-spc/ubuntu/metpx-daily librabbitmq +Ubuntu 18.04 +++++++++++++ + +Pour ubuntu 18.04 (bionique), il y a quelques problèmes. La recette s’appelle: metpx-sr3-daily-bionic, et il +prend la source à partir d’une branche différente : *v03_launchpad*. Pour chaque version, cette branche +doit être rebasée à partir de *development* + +* git checkout v03_launchpad +* git rebase -i development +* git push +* import source +* Request build from *metpx-sr3-daily-bionic* Recipe. + +En quoi cette branche *v03_launchpad* est-elle différente ? Elle: + +* Supprime la dépendance sur python3-paho-mqtt car la version dans le *repository* d´ubuntu est trop ancienne. +* Suppression de la dépendance sur python3-dateparser, car ce paquet n’est pas disponible dans le *repository* d´ubuntu. +* remplacer la cible de test dans debian/rules, parce que tester sans les dépendances échoue :: + + override_dh_auto_test: + echo "disable on 18.04... some deps must come from pip" + +The missing dependencies should be installed with pip3. + + + +Création d’un programme d’installation Windows +++++++++++++++++++++++++++++++++++++++++++++++ + +On peut également construire un programme d’installation Windows avec cela +`script `_. +Il doit être exécuté à partir d’un système d’exploitation Linux (de préférence Ubuntu 18) +dans le répertoire racine de git de Sarracenia. + +déterminer la version de python:: + + fractal% python -V + Python 3.10.12 + fractal% + + +C'est donc python 3.10. Une seule version mineure aura le package intégré nécessaire +par pynsist pour construire l'exécutable. On valide chez:: + + https://www.python.org/downloads/windows/ + +afin to confirmer que la version avec un binaire *embedded* pour 3.10 et le 3.10.11 +Ensuite, à partir du shell, exécutez :: + + sudo apt install nsis + pip3 install pynsist wheel + ./generate-win-installer.sh 3.10.11 2>&1 > log.txt + +Le paquet final doit être placé dans le répertoire build/nsis. + + + +github +------ + +Cliquez sur Releases, modifiez la release : + +* Devrions-nous avoir des noms de sortie? +* copier/coller des modifications de CHANGES.rst +* copier/coller le bit d’installation à la fin d’une version précédente. +* Construire des paquets localement ou télécharger à partir d’autres sources. + Glissez-déposez dans la version. + +Cela nous donnera la possibilité d’avoir d’anciennes versions disponibles. +launchpad.net ne semble pas garder les anciennes versions. + + + +ubuntu 18 +--------- + +Problème rencontre lors de géneration de pacque pour pypi.org sur ubuntu 18:: + + buntu@canny-tick:~/sr3$ twine upload dist/metpx_sr3-3.0.53rc2-py3-none-any.whl + /usr/lib/python3/dist-packages/requests/__init__.py:80: RequestsDependencyWarning: urllib3 (1.26.18) or chardet (3.0.4) doesn't match a supported version! + RequestsDependencyWarning) + Uploading distributions to https://upload.pypi.org/legacy/ + Uploading metpx_sr3-3.0.53rc2-py3-none-any.whl + 100%|██████████████████████████████████████████████████████████████████████████████████████████████████| 408k/408k [00:00<00:00, 120kB/s] + HTTPError: 400 Client Error: '2.0' is not a valid metadata version. See https://packaging.python.org/specifications/core-metadata for more information. for url: https://upload.pypi.org/legacy/ + ubuntu@canny-tick:~/sr3$ + +On a générer via redhat8 à la place. Il semble que la version de twine de ubuntu 18 ne soit plus +en mésure de communiquer avec pypi.org. installation avec pip3 aura peut-être aussi regler le bobo. diff --git a/docs/source/fr/Contribution/index.rst b/docs/source/fr/Contribution/index.rst index 02f9dfb3f..ec043cfb3 100644 --- a/docs/source/fr/Contribution/index.rst +++ b/docs/source/fr/Contribution/index.rst @@ -8,6 +8,7 @@ Contribuer à Sarracenia Développement Documentation + Publication modèle_de_page_man.rst v03 Original (2015) Idée de base