+1 for the pcreech {datadir} plan. If we go with the pcreech plan, I am -0 on using `pulpproj` for our PyPI name. If we are not using the PyPI name at import time, then the length problem [0] no longer exists, and we are abbreviating without a good reason. I think "pulpproject" would be best, since it matches our website. We want our users to have to remember as little as possible.
[0]: https://pulp.plan.io/issues/2444#note-8 On Mon, Apr 10, 2017 at 11:45 AM, Brian Bouterse <bbout...@redhat.com> wrote: > After considering @pcreech's point, +1 installing Pulp in {datadir} and > having it install there using setup.cfg options. In terms of setting the > PYTHONPATH at runtime, it would be best if we could have the Python code do > it itself at startup. As an alternative we could do it with the systemd > units, but then on other distros they would have to figure it out all again > so by doing it in the processes themselves we would avoid that. > > We still need to pick the PyPI names we would distribute with, but this > would allow us to have all imports be: > > from pulp import .... > > or for plugins > > from pulp_rpm import ..... > > -Brian > > On Fri, Apr 7, 2017 at 5:59 PM, Patrick Creech <pcre...@redhat.com> wrote: > >> I've been doing some preliminary research into a 'Have our cake and eat >> it too' option. >> >> While getting back up to speed on things pulp, I came across this comment >> on the FPC ticket: >> >> https://pagure.io/packaging-committee/issue/671#comment-146777 >> >> Buried towards the end of this comment, in the second to last paragraph, >> is a statement of interest >> from a packaging perspective: >> >> "Moving the common library out of %{site_packages}/pulp and into, for >> instance, >> %{_datadir}/pulp_common/pulp will also fix the conflict". >> >> Something to consider, our Pulp project is not intended to be a general >> purpose system library. It >> is for pulp purposes only (and pulp plugins). With that, we don't >> necessarily need to live in site- >> packages. FWIW, we do something similar with the SCL that was created. >> >> We will have to modify pulp tooling to either set PYTHONPATH (bash >> script) or sys.path (python >> script), but this allows us to keep 'import pulp' while preventing >> conflicts with the PuLP project. >> This also addresses the Fedora package collision by moving our files out >> of site-packages as well, >> removing the RPM file collision. >> >> After doing some reading on setuptools, we can specify "setup.py install" >> options in setup.cfg, >> allowing us to do this across various ways of distributing our software. >> >> The last piece is how pypi will treat this (as it was expressed to me >> that pip install pulp_project >> is of interest). My initial reading seems to suggest this as 'just >> works' with the setup.cfg, but I >> would like to verify this. >> >> Thoughts? >> >> Patrick >> >> >> _______________________________________________ >> Pulp-dev mailing list >> Pulp-dev@redhat.com >> https://www.redhat.com/mailman/listinfo/pulp-dev >> >> > > _______________________________________________ > Pulp-dev mailing list > Pulp-dev@redhat.com > https://www.redhat.com/mailman/listinfo/pulp-dev > >
_______________________________________________ Pulp-dev mailing list Pulp-dev@redhat.com https://www.redhat.com/mailman/listinfo/pulp-dev