Re: [oi-dev] FLAG-DAY: We started to obsolete python 2.7 and 3.5
For the specific case of library/python/mkdocs which is now obsolete, changing/updating the docs.openindiana.org is a solution. The webpage for documenation specifically says that most operating systems use: "pip install mkdocs" So by removing the documentation on "pkg install mkdocs" this can be solved. - Op 29 sep 2022 om 18:46 schreef stes s...@telenet.be: >> Based on the rule above we already obsoleted following packages >> recently: >> > ... >> library/python/mkdocs > ... > > see http://docs.openindiana.org/contrib/getting-started/ > > that page says for installing mkdocs: > > "For OpenIndiana Hipster, MKDocs and all of it's dependencies have been > packaged > and are available in the OI Hipster repository. So, if you're already running > Hipster, installing MKDocs is as simple as: pkg install mkdocs" > > > also my vagrant image for oi-docs is using the IPS mkdocs package: > > https://github.com/OpenIndiana/vagrantfiles > > I can confirm that there's problems with the mkdocs IPS package as it is based > on the old 2.7 Python. > > David Stes > > ___ > oi-dev mailing list > oi-dev@openindiana.org > https://openindiana.org/mailman/listinfo/oi-dev ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] FLAG-DAY: We started to obsolete python 2.7 and 3.5
> Based on the rule above we already obsoleted following packages > recently: > ... > library/python/mkdocs ... see http://docs.openindiana.org/contrib/getting-started/ that page says for installing mkdocs: "For OpenIndiana Hipster, MKDocs and all of it's dependencies have been packaged and are available in the OI Hipster repository. So, if you're already running Hipster, installing MKDocs is as simple as: pkg install mkdocs" also my vagrant image for oi-docs is using the IPS mkdocs package: https://github.com/OpenIndiana/vagrantfiles I can confirm that there's problems with the mkdocs IPS package as it is based on the old 2.7 Python. David Stes ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] FLAG-DAY: We started to obsolete python 2.7 and 3.5
On Thu, Sep 29, 2022 at 04:36:15PM +0200, Aurélien Larcher wrote: > On Thu, Sep 29, 2022 at 4:30 PM Marcel Telka wrote: > > > On Thu, Sep 29, 2022 at 04:18:01PM +0200, Aurélien Larcher wrote: > > > We could define some rules or information depending on the nature of the > > > package to mark which dependencies are expected. > > > Some python modules have been added for the sake of resolving a > > dependency > > > while others have no consumer in userland but are expected to be > > installed > > > as "standalone" and consumed by users directly. > > > > > > Also I am not sure I understood which type of dependencies are considered > > > here: > > > - resolved within userland either directly or added explicitly in the > > > manifest > > > - build requirements > > > - dependencies detected by pipdeptree (which are a superset of what > > > pkg/userland detects) > > > > > > I just want to make sure that we do not miss some border effects. > > > > Okay, I'll stop to obsolete more python related packages and leave it as > > it is for now so everybody have a chance to add back packages that were > > obsoleted, but they are needed for any reason. > > > > I am not asking you to stop anything at all, I am just asking questions to > understand if this will not bite us back at some point. I won't obsolete any package from the list below until end of October 2022. If I see no PR trying to rebuild them to support python 3.7+ till end of October 2022, then I might propose to obsolete them. library/python/backport_abc library/python/backports.functools_lru_cache library/python/backports.ssl_match_hostname library/python/colorama library/python/decorator library/python/enum library/python/flamegraph library/python/funcsigs library/python/ipaddress library/python/ipython library/python/ipython_genutils library/python/notify2 library/python/pickleshare library/python/prompt-toolkit library/python/pyatspi2 library/python/pycups library/python/pygobject library/python/pygtk2 library/python/python-compizconfig library/python/python-xdg library/python/python-xlib library/python/rbtools library/python/simplegeneric library/python/traitlets Thanks. -- +---+ | Marcel Telka e-mail: mar...@telka.sk | |homepage: http://telka.sk/ | +---+ ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] FLAG-DAY: We started to obsolete python 2.7 and 3.5
On Thu, Sep 29, 2022 at 04:36:15PM +0200, Aurélien Larcher wrote: > At least maybe some indications on how to add the packages back and make > sure there is no mistake or loss of consistency with the location/naming > etc.. If anybody wants to re-add some obsoleted package back, or rebuild some package to support python 3.7/3.9 properly and have some questions, issues, problems, etc. feel free to ask me. I'll try to help. Thanks. -- +---+ | Marcel Telka e-mail: mar...@telka.sk | |homepage: http://telka.sk/ | +---+ ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] FLAG-DAY: We started to obsolete python 2.7 and 3.5
On Thu, Sep 29, 2022 at 4:30 PM Marcel Telka wrote: > On Thu, Sep 29, 2022 at 04:18:01PM +0200, Aurélien Larcher wrote: > > We could define some rules or information depending on the nature of the > > package to mark which dependencies are expected. > > Some python modules have been added for the sake of resolving a > dependency > > while others have no consumer in userland but are expected to be > installed > > as "standalone" and consumed by users directly. > > > > Also I am not sure I understood which type of dependencies are considered > > here: > > - resolved within userland either directly or added explicitly in the > > manifest > > - build requirements > > - dependencies detected by pipdeptree (which are a superset of what > > pkg/userland detects) > > > > I just want to make sure that we do not miss some border effects. > > Okay, I'll stop to obsolete more python related packages and leave it as > it is for now so everybody have a chance to add back packages that were > obsoleted, but they are needed for any reason. > I am not asking you to stop anything at all, I am just asking questions to understand if this will not bite us back at some point. If you feel that you have everything covered then it is fine by me. Seeing the stream of obsoletions without warning was quite surprising and raised a few questions. You know how you want to handle things, but this is maybe less clear to others. At least maybe some indications on how to add the packages back and make sure there is no mistake or loss of consistency with the location/naming etc.. Kind regards, Aurélien > > -- > +---+ > | Marcel Telka e-mail: mar...@telka.sk | > |homepage: http://telka.sk/ | > +---+ > > ___ > oi-dev mailing list > oi-dev@openindiana.org > https://openindiana.org/mailman/listinfo/oi-dev > -- --- Praise the Caffeine embeddings ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] FLAG-DAY: We started to obsolete python 2.7 and 3.5
On Thu, Sep 29, 2022 at 04:18:01PM +0200, Aurélien Larcher wrote: > We could define some rules or information depending on the nature of the > package to mark which dependencies are expected. > Some python modules have been added for the sake of resolving a dependency > while others have no consumer in userland but are expected to be installed > as "standalone" and consumed by users directly. > > Also I am not sure I understood which type of dependencies are considered > here: > - resolved within userland either directly or added explicitly in the > manifest > - build requirements > - dependencies detected by pipdeptree (which are a superset of what > pkg/userland detects) > > I just want to make sure that we do not miss some border effects. Okay, I'll stop to obsolete more python related packages and leave it as it is for now so everybody have a chance to add back packages that were obsoleted, but they are needed for any reason. -- +---+ | Marcel Telka e-mail: mar...@telka.sk | |homepage: http://telka.sk/ | +---+ ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] FLAG-DAY: We started to obsolete python 2.7 and 3.5
On Thu, Sep 29, 2022 at 4:00 PM Marcel Telka wrote: > On Thu, Sep 29, 2022 at 03:18:29PM +0200, Aurélien Larcher wrote: > > I do not understand the need for obsoleting the entire package and > removing > > all the files instead of updating on the go. > > > > Could you explain the motivation? > > There is no particular need. It is just simpler to obsolete than to > update. And since there is no known consumer, then the obsoletion is > the obvious option chosen. > We could define some rules or information depending on the nature of the package to mark which dependencies are expected. Some python modules have been added for the sake of resolving a dependency while others have no consumer in userland but are expected to be installed as "standalone" and consumed by users directly. Also I am not sure I understood which type of dependencies are considered here: - resolved within userland either directly or added explicitly in the manifest - build requirements - dependencies detected by pipdeptree (which are a superset of what pkg/userland detects) I just want to make sure that we do not miss some border effects. > > > To me this seems a bit of overhead, like removing the mkdocs, cython, > numpy > > packages completely from the tree instead of updating them. > > Feel free to create PRs to get them back. > > > We therefore lose track of what was in the tree and people may start from > > scratch all over again. > > > > Maybe you intend to provide some level of automation later? > > Maybe. If I find it easy to do I'll do so, but I've no immediate plan > to do so. > > > An earlier heads-up before starting to remove everything could have been > > nice to have a chance to update a few components in advance and avoid the > > mumbo-jumbo. > > Sorry. I try to do my best. Nothing is perfect. > > Anyway, an earlier update/rebuild of those packages for non-EOLed python > would be nice from you before you left them fall out of support and be > surprised that they are disappearing. > > Sorry, talking is easy. > > > Thank you. > > -- > +---+ > | Marcel Telka e-mail: mar...@telka.sk | > |homepage: http://telka.sk/ | > +---+ > > ___ > oi-dev mailing list > oi-dev@openindiana.org > https://openindiana.org/mailman/listinfo/oi-dev > -- --- Praise the Caffeine embeddings ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] FLAG-DAY: We started to obsolete python 2.7 and 3.5
On Thu, Sep 29, 2022 at 4:00 PM Marcel Telka wrote: > On Thu, Sep 29, 2022 at 03:18:29PM +0200, Aurélien Larcher wrote: > > I do not understand the need for obsoleting the entire package and > removing > > all the files instead of updating on the go. > > > > Could you explain the motivation? > > There is no particular need. It is just simpler to obsolete than to > update. And since there is no known consumer, then the obsoletion is > the obvious option chosen. > > > To me this seems a bit of overhead, like removing the mkdocs, cython, > numpy > > packages completely from the tree instead of updating them. > > Feel free to create PRs to get them back. > > > We therefore lose track of what was in the tree and people may start from > > scratch all over again. > > > > Maybe you intend to provide some level of automation later? > > Maybe. If I find it easy to do I'll do so, but I've no immediate plan > to do so. > > > An earlier heads-up before starting to remove everything could have been > > nice to have a chance to update a few components in advance and avoid the > > mumbo-jumbo. > > Sorry. I try to do my best. Nothing is perfect. > Sure, just at least a few days would be fine. Some of us cannot check the ML on a daily basis. > > Anyway, an earlier update/rebuild of those packages for non-EOLed python > would be nice from you before you left them fall out of support and be > surprised that they are disappearing. > > Sorry, talking is easy. > You are probably using this argument with the wrong person (you can look at the git history for example) but fair enough, I do not like talking for nothing either, just a discussion now and then to keep consistency across all the participants. > > > Thank you. > > -- > +---+ > | Marcel Telka e-mail: mar...@telka.sk | > |homepage: http://telka.sk/ | > +---+ > > ___ > oi-dev mailing list > oi-dev@openindiana.org > https://openindiana.org/mailman/listinfo/oi-dev > -- --- Praise the Caffeine embeddings ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] FLAG-DAY: We started to obsolete python 2.7 and 3.5
On Thu, Sep 29, 2022 at 03:18:29PM +0200, Aurélien Larcher wrote: > I do not understand the need for obsoleting the entire package and removing > all the files instead of updating on the go. > > Could you explain the motivation? There is no particular need. It is just simpler to obsolete than to update. And since there is no known consumer, then the obsoletion is the obvious option chosen. > To me this seems a bit of overhead, like removing the mkdocs, cython, numpy > packages completely from the tree instead of updating them. Feel free to create PRs to get them back. > We therefore lose track of what was in the tree and people may start from > scratch all over again. > > Maybe you intend to provide some level of automation later? Maybe. If I find it easy to do I'll do so, but I've no immediate plan to do so. > An earlier heads-up before starting to remove everything could have been > nice to have a chance to update a few components in advance and avoid the > mumbo-jumbo. Sorry. I try to do my best. Nothing is perfect. Anyway, an earlier update/rebuild of those packages for non-EOLed python would be nice from you before you left them fall out of support and be surprised that they are disappearing. Sorry, talking is easy. Thank you. -- +---+ | Marcel Telka e-mail: mar...@telka.sk | |homepage: http://telka.sk/ | +---+ ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] FLAG-DAY: We started to obsolete python 2.7 and 3.5
On Thu, Sep 29, 2022 at 2:25 PM Marcel Telka wrote: > Hi, > > Currently we provide Python versions 2.7, 3.5, 3.7, and 3.9 for > OpenIndiana, while version 3.9 is the default version. > > Both Python 2.7 and 3.5 are no longer supported for two or almost three > years now respectively - see > https://devguide.python.org/versions/#versions for details, so we > started to obsolete them. Since there are many related packages that > needs to be rebuilt to get python 2.7 and 3.5 obsoleted, this transition > is expected to take long time (probably weeks, maybe months). > > There are basically two sets of related packages: > > #1 software that uses python (e.g. gimp), and > #2 packages that provide some enhancement to python; these are usually >python modules, for example cherrypy. > > For #1 we just need to rebuild packages that require python 2.7 or 3.5 > so they start to require either python 3.7, or python 3.9. Volunteers > are welcome! > > For #2 the situation is a bit more complex. The name of all packages in > this set is starting with 'library/python'. There is usually a basic > package (e.g. library/python/cherrypy) and few version specific packages > (e.g. library/python/cherrypy-35, library/python/cherrypy-37, > library/python/cherrypy-39). Another example is library/python/pycups > and its library/python/pycups-27 and library/python/pycups-35. > > For such packages we will slowly obsolete their -27 and -35 variants. > In a case there is neither -37 nor -39 variant already available, nor it > is needed for some other package, we will end up with all package > variants obsoleted. If this happens, then in addition to obsolete of > both -27 and -35 we will obsolete the base package too. > > For example, cherrypy. There are already -35, -37, and -39 variants. > We will obsolete the -35 variant and both -37 and -39 will be kept, so > we will keep the basic library/python/cherrypy too. > > When looking at pycups, we will obsolete both -27 and -35 variants. > Let's assume there is currently no other package that needs pycups, so > we would end with orphaned library/python/pycups, so we will obsolete > the library/python/pycups package too. > > Based on the rule above we already obsoleted following packages > recently: > > library/python/augeas > library/python/backports.shutil_get_terminal_size > library/python/backports.tempfile > library/python/cheetah > library/python/click > library/python/cssutils > library/python/cython > library/python/dulwich > library/python/geoip > library/python/elixir > library/python/import-profiler > library/python/kafka-python > library/python/livereload > library/python/m2crypto > library/python/mkdocs-bootstrap > library/python/mkdocs-bootswatch > library/python/mkdocs > library/python/netaddr > library/python/netifaces > library/python/numpy > library/python/pygtksourceview > library/python/pymongo > library/python/pyorbit > library/python/pyrex > library/python/pyro > library/python/python-ldap > library/python/python-memcached > library/python/python-mysql > library/python/python-notify > library/python/python-sexy > library/python/pywbem > library/python/scientific-py > library/python/sqlalchemy > library/python/typing > library/python/unittest2 > > Here is a list of packages that could get possibly obsoleted soon: > > library/python/backport_abc > library/python/backports.functools_lru_cache > library/python/backports.ssl_match_hostname > library/python/colorama > library/python/decorator > library/python/enum > library/python/flamegraph > library/python/funcsigs > library/python/ipaddress > library/python/ipython > library/python/ipython_genutils > library/python/notify2 > library/python/pickleshare > library/python/prompt-toolkit > library/python/pyatspi2 > library/python/pycups > library/python/pygobject > library/python/pygtk2 > library/python/python-compizconfig > library/python/python-xdg > library/python/python-xlib > library/python/rbtools > library/python/simplegeneric > library/python/traitlets > > If you need any package from these lists then please create a pull > request (see https://github.com/OpenIndiana/oi-userland/pulls) to get > the package back and built for python 3.7 and/or 3.9 (in a case it is on > the first list of already obsoleted packages), or either let us know or > create a pull request to rebuild the package for python 3.7 and/or 3.9 > (if it is on the second list of packages we could possibly obsolete). > > Any help with this task is very welcome (for example pull requests to > get software in set #1 rebuilt). > > Please note that support for building python modules for python 2.7 and > 3.5 was already dropped from oi-userland. > I do not understand the need for obsoleting the entire package and removing all the files instead of updating on the go. Could you explain the motivation? To me this seems a bit of overhead, like removing the mkdocs, cython, numpy packages completely from the tree instead of updating them. We therefore
[oi-dev] FLAG-DAY: We started to obsolete python 2.7 and 3.5
Hi, Currently we provide Python versions 2.7, 3.5, 3.7, and 3.9 for OpenIndiana, while version 3.9 is the default version. Both Python 2.7 and 3.5 are no longer supported for two or almost three years now respectively - see https://devguide.python.org/versions/#versions for details, so we started to obsolete them. Since there are many related packages that needs to be rebuilt to get python 2.7 and 3.5 obsoleted, this transition is expected to take long time (probably weeks, maybe months). There are basically two sets of related packages: #1 software that uses python (e.g. gimp), and #2 packages that provide some enhancement to python; these are usually python modules, for example cherrypy. For #1 we just need to rebuild packages that require python 2.7 or 3.5 so they start to require either python 3.7, or python 3.9. Volunteers are welcome! For #2 the situation is a bit more complex. The name of all packages in this set is starting with 'library/python'. There is usually a basic package (e.g. library/python/cherrypy) and few version specific packages (e.g. library/python/cherrypy-35, library/python/cherrypy-37, library/python/cherrypy-39). Another example is library/python/pycups and its library/python/pycups-27 and library/python/pycups-35. For such packages we will slowly obsolete their -27 and -35 variants. In a case there is neither -37 nor -39 variant already available, nor it is needed for some other package, we will end up with all package variants obsoleted. If this happens, then in addition to obsolete of both -27 and -35 we will obsolete the base package too. For example, cherrypy. There are already -35, -37, and -39 variants. We will obsolete the -35 variant and both -37 and -39 will be kept, so we will keep the basic library/python/cherrypy too. When looking at pycups, we will obsolete both -27 and -35 variants. Let's assume there is currently no other package that needs pycups, so we would end with orphaned library/python/pycups, so we will obsolete the library/python/pycups package too. Based on the rule above we already obsoleted following packages recently: library/python/augeas library/python/backports.shutil_get_terminal_size library/python/backports.tempfile library/python/cheetah library/python/click library/python/cssutils library/python/cython library/python/dulwich library/python/geoip library/python/elixir library/python/import-profiler library/python/kafka-python library/python/livereload library/python/m2crypto library/python/mkdocs-bootstrap library/python/mkdocs-bootswatch library/python/mkdocs library/python/netaddr library/python/netifaces library/python/numpy library/python/pygtksourceview library/python/pymongo library/python/pyorbit library/python/pyrex library/python/pyro library/python/python-ldap library/python/python-memcached library/python/python-mysql library/python/python-notify library/python/python-sexy library/python/pywbem library/python/scientific-py library/python/sqlalchemy library/python/typing library/python/unittest2 Here is a list of packages that could get possibly obsoleted soon: library/python/backport_abc library/python/backports.functools_lru_cache library/python/backports.ssl_match_hostname library/python/colorama library/python/decorator library/python/enum library/python/flamegraph library/python/funcsigs library/python/ipaddress library/python/ipython library/python/ipython_genutils library/python/notify2 library/python/pickleshare library/python/prompt-toolkit library/python/pyatspi2 library/python/pycups library/python/pygobject library/python/pygtk2 library/python/python-compizconfig library/python/python-xdg library/python/python-xlib library/python/rbtools library/python/simplegeneric library/python/traitlets If you need any package from these lists then please create a pull request (see https://github.com/OpenIndiana/oi-userland/pulls) to get the package back and built for python 3.7 and/or 3.9 (in a case it is on the first list of already obsoleted packages), or either let us know or create a pull request to rebuild the package for python 3.7 and/or 3.9 (if it is on the second list of packages we could possibly obsolete). Any help with this task is very welcome (for example pull requests to get software in set #1 rebuilt). Please note that support for building python modules for python 2.7 and 3.5 was already dropped from oi-userland. Thank you. -- +---+ | Marcel Telka e-mail: mar...@telka.sk | |homepage: http://telka.sk/ | +---+ ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
