> > You say it is also possible to use '*pip2 install .*' from the root of a > svn or git cloned repo. That would only replace my .egg building and > copying. I still need to pull or sync my repos. I guess maintaining a > requirements_file is the best as you say. '*pip2 list --user --outdated*' > shows me the available updates and '*pip2 install --user -Ur > requirement_file'* applies the updates. There would only be the gap if > there is a new version on SVN that is not published on PyPI yet, so I still > need to monitor those a bit.
With compatibility between various plug-ins and Trac-versions being highly version sensitive, packages on PyPI etc being sporadically updated, and occasionally needing to make some instance-specific customizations at the module-level, I've been using Pip's VCS capability to target specific branches and tagged versions and install the sources rather than eggs or wheels. https://pip.pypa.io/en/stable/reference/pip_install/#vcs-support Requirements files support specifying VCS options as well: https://pip.pypa.io/en/stable/reference/pip_install/#requirements-file-format Pip can still fetch supporting libs and such from PyPI, if needed. About the virtual environment that was recommended many times to me I don't > see the advantage yet. As I have all the Trac installation concentrated to > the ~trac/ now, this $HOME is isolated from the root installation anyway. > Then I'm daily btrfs-snapshotting the home directories. That virtualenv > sounds like perlbrew, having a portable complete installation with > interpreter and libraries. This would be helpful if I need separated > installations for the trac user account. Do I need this? My isolated python > environment is ~trac/.local/ managed by '*pip2 install --user*'. It sounds like your setup fulfills many of the same needs that a virtual environment would. If it's working for you I wouldn't see much point in scrapping it. Virtual environments can offer further capabilities in terms of other Python tooing interacting with them programatically, such as using Pipenv to make reproducible builds that include a v. e. and invoke things within its context. A good tool to have in the toolbox, even if you stick with what you've got for your Trac setup. Some parts I found from the linux distribution like > dev-python/simplejson-3.16.0 I installed as root, but I guess if those are > only requred by Trac I would also move them to the ~trac/ home, as PyPI > could be more up to date as some Linux distribution. I recommend isolating any Python 2 dependencies Trac has from your system Python sooner rather than later. Gentoo gives you a great deal of flexibility there, of course, but distro maintainers generally are moving faster on transitioning to Python 3 than Trac is (understandable with Trac's small developer pool and the DB API & Jinja transitions also demanding their attention). Best, --Jonathan Laufersweiler On Fri, Nov 15, 2019 at 1:42 AM Mo <burcheri.mass...@gmail.com> wrote: > Thank you very much. > I think it's a good idea to use such a requirements_file, eventhough I > still think it's part of a package manager to populate such a file after a > '*pip > install*', just like every rpm, apt, yum or portage does. > > Who is reponsible for publishing to PyPI? Does every track-hacks plugin > author need to push to PyPI and such a request to do so I should file on > track-hacks? The usual plugin wiki does mention the SVN source, but no > comments about availability on PyPI. > I don't know much about PyPI, but if there was kind of repositories for > pip it would be better to find all plugins on a separated trac repository > instead of pushing every single trac plugin to the big PyPI repo. But it > seems to be one big repository and Trac components usually are names like > "Trac*". Though it is hard to find the packages, as for instance '*pip2 > search AccountManager*' does not find it while '*pip2 search > TracAccountManager*' finds the (outdated) 0.5.0 version. > > You say it is also possible to use '*pip2 install .*' from the root of a > svn or git cloned repo. That would only replace my .egg building and > copying. I still need to pull or sync my repos. I guess maintaining a > requirements_file is the best as you say. '*pip2 list --user --outdated*' > shows me the available updates and '*pip2 install --user -Ur > requirement_file'* applies the updates. There would only be the gap if > there is a new version on SVN that is not published on PyPI yet, so I still > need to monitor those a bit. > > About the virtual environment that was recommended many times to me I > don't see the advantage yet. As I have all the Trac installation > concentrated to the ~trac/ now, this $HOME is isolated from the root > installation anyway. Then I'm daily btrfs-snapshotting the home directories. > That virtualenv sounds like perlbrew, having a portable complete > installation with interpreter and libraries. This would be helpful if I > need separated installations for the trac user account. Do I need this? My > isolated python environment is ~trac/.local/ managed by '*pip2 install > --user*'. > > For now, only packages like dev-lang/python-2.7.17, > dev-python/pip-19.3.1,dev-python/setuptools-41.5.1 are provided by the > linux root installation. Trac itself and Trac required python packages like > pymills, reportlab or xhtml2pdf are installed by pip to the ~trac/ home, > and Trac plugins are installed as .eggs to > ~trac/projects/trac-pp/plugins/. I'm going to reduce the local .eggs and > move that to pip as well. > > Some parts I found from the linux distribution like > dev-python/simplejson-3.16.0 I installed as root, but I guess if those are > only requred by Trac I would also move them to the ~trac/ home, as PyPI > could be more up to date as some Linux distribution. > > -- > You received this message because you are subscribed to the Google Groups > "Trac Users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to trac-users+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/trac-users/b7e36fb6-c903-4c43-83cf-a467c46fb21c%40googlegroups.com > <https://groups.google.com/d/msgid/trac-users/b7e36fb6-c903-4c43-83cf-a467c46fb21c%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- You received this message because you are subscribed to the Google Groups "Trac Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to trac-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/trac-users/CALF_GDEBko%2BkPQVS_rn7sCuSoBviGq6VXU%3DfFcPCvq%3DL%3DX4GjA%40mail.gmail.com.
