<div dir="ltr">The "datadir" idea is a good option to have, and I can see how it could work. That said, it has a couple of drawbacks worth considering.<div><br></div><div>1) I regularly think about the Principle of Least Surprise, and it applies well here. Python devs know that python code usually goes in site-packages. Not finding Pulp code there would be surprising in most cases. It may work great and be completely valid, but I think we should have a very good reason before straying from such a convention. Python packaging is a complicated enough topic as it is (see - vs _, setuptools vs. distutil vs distribute, package name vs. python namespace, etc), that I think we will benefit from sticking to defaults when possible and reasonable.</div><div><br></div><div>This aspect is definitely not a deal-breaker. I'm sure other apps do this successfully. It's just a factor that makes me lean another direction.</div><div><br></div><div>2) This would not entirely eliminate the namespace collision, if we continued using the "pulp" namespace in python. Keep in mind that we're not just worried about a collision in site-packages; we're worried about a collision at runtime in the interpreter's global namespace. If we add a new location to PYTHONPATH, but the "pulp" namespace is used in the new location AND in site-packages, that's asking for trouble. Maybe it would work ok by completely overshadowing the "pulp" in site-packages (I'm not sure if it would), but it seems safer to just use a different namespace than "pulp".</div><div><br></div><div>And if we use a different namespace than "pulp", I don't think we gain anything from installing to a separate location.</div><div><br></div><div>This also may not be a deal-breaker, but it nudges me in the direction of just using a non-"pulp" name in the standard location.</div><div><br></div><div>Thanks Patrick for raising this as an option.</div><div><br></div><div>Michael</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Apr 10, 2017 at 3:58 PM, Austin Macdonald <span dir="ltr"><<a href="mailto:amacdona@redhat.com" target="_blank">amacdona@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>+1 for the pcreech {datadir} plan.</div><div><br></div><div>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.</div><div><div><br></div><div>[0]: <a href="https://pulp.plan.io/issues/2444#note-8" target="_blank">https://pulp.plan.io/<wbr>issues/2444#note-8</a></div></div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Apr 10, 2017 at 11:45 AM, Brian Bouterse <span dir="ltr"><<a href="mailto:bbouters@redhat.com" target="_blank">bbouters@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div><div>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.<br><br>We still need to pick the PyPI names we would distribute with, but this would allow us to have all imports be:<br><br></div>from pulp import ....<br><br></div>or for plugins<br><br></div>from pulp_rpm import .....<span class="m_3508342093091967283HOEnZb"><font color="#888888"><br><br></font></span></div><span class="m_3508342093091967283HOEnZb"><font color="#888888">-Brian<br></font></span></div><div class="gmail_extra"><br><div class="gmail_quote"><div><div class="m_3508342093091967283h5">On Fri, Apr 7, 2017 at 5:59 PM, Patrick Creech <span dir="ltr"><<a href="mailto:pcreech@redhat.com" target="_blank">pcreech@redhat.com</a>></span> wrote:<br></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="m_3508342093091967283h5">I've been doing some preliminary research into a 'Have our cake and eat it too' option.<br>
<br>
While getting back up to speed on things pulp, I came across this comment on the FPC ticket:<br>
<br>
    <a href="https://pagure.io/packaging-committee/issue/671#comment-146777" rel="noreferrer" target="_blank">https://pagure.io/packaging-co<wbr>mmittee/issue/671#comment-1467<wbr>77</a><br>
<br>
Buried towards the end of this comment, in the second to last paragraph, is a statement of interest<br>
from a packaging perspective:<br>
<br>
    "Moving the common library out of %{site_packages}/pulp and into, for instance,<br>
%{_datadir}/pulp_common/pulp will also fix the conflict".<br>
<br>
Something to consider, our Pulp project is not intended to be a general purpose system library.  It<br>
is for pulp purposes only (and pulp plugins).  With that, we don't necessarily need to live in site-<br>
packages.  FWIW, we do something similar with the SCL that was created.<br>
<br>
We will have to modify pulp tooling to either set PYTHONPATH (bash script) or sys.path (python<br>
script), but this allows us to keep 'import pulp' while preventing conflicts with the PuLP project.<br>
This also addresses the Fedora package collision by moving our files out of site-packages as well,<br>
removing the RPM file collision.<br>
<br>
After doing some reading on setuptools, we can specify "setup.py install" options in setup.cfg,<br>
allowing us to do this across various ways of distributing our software.<br>
<br>
The last piece is how pypi will treat this (as it was expressed to me that pip install pulp_project<br>
is of interest).  My initial reading seems to suggest this as 'just works' with the setup.cfg, but I<br>
would like to verify this.<br>
<br>
Thoughts?<br>
<span class="m_3508342093091967283m_-6791821257877153702HOEnZb"><font color="#888888"><br>
Patrick<br>
<br>
</font></span><br></div></div><span>______________________________<wbr>_________________<br>
Pulp-dev mailing list<br>
<a href="mailto:Pulp-dev@redhat.com" target="_blank">Pulp-dev@redhat.com</a><br>
<a href="https://www.redhat.com/mailman/listinfo/pulp-dev" rel="noreferrer" target="_blank">https://www.redhat.com/mailman<wbr>/listinfo/pulp-dev</a><br>
<br></span></blockquote></div><br></div>
<br>______________________________<wbr>_________________<br>
Pulp-dev mailing list<br>
<a href="mailto:Pulp-dev@redhat.com" target="_blank">Pulp-dev@redhat.com</a><br>
<a href="https://www.redhat.com/mailman/listinfo/pulp-dev" rel="noreferrer" target="_blank">https://www.redhat.com/mailman<wbr>/listinfo/pulp-dev</a><br>
<br></blockquote></div><br></div>
</div></div><br>______________________________<wbr>_________________<br>
Pulp-dev mailing list<br>
<a href="mailto:Pulp-dev@redhat.com">Pulp-dev@redhat.com</a><br>
<a href="https://www.redhat.com/mailman/listinfo/pulp-dev" rel="noreferrer" target="_blank">https://www.redhat.com/<wbr>mailman/listinfo/pulp-dev</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><p style="color:rgb(0,0,0);font-family:overpass-mono,monospace;font-size:10px;margin:0px!important;padding:0px!important"><span style="margin:0px!important;padding:0px!important">Michael</span> <span style="margin:0px!important;padding:0px!important">Hrivnak</span></p><p style="color:rgb(0,0,0);font-family:overpass-mono,monospace;font-size:10px;margin:0px!important;padding:0px!important"></p><span style="color:rgb(0,0,0);font-family:overpass-mono,monospace;font-size:10px;margin:0px!important;padding:0px!important"><span style="margin:0px!important;padding:0px!important">Principal Software Engineer</span><span style="margin:0px!important;padding:0px!important">, <span style="margin:0px!important;padding:0px!important">RHCE</span></span> </span><span style="color:rgb(0,0,0);font-family:overpass-mono,monospace;font-size:10px"></span><br style="color:rgb(0,0,0);font-family:overpass-mono,monospace;font-size:10px;margin:0px!important;padding:0px!important"><p style="color:rgb(0,0,0);font-family:overpass-mono,monospace;font-size:10px;margin:0px!important;padding:0px!important">Red Hat</p></div></div>
</div>