I like using the pulp3 namespace. On Tue, Apr 11, 2017 at 9:13 AM, Bihan Zhang <bizh...@redhat.com> wrote:
> What about pulp3 as a potential namespace? With this naming we can > communicate that this PyPI package is Pulp3 (not Pulp2), and that it is > Python3 compatible. > > There's plenty of PyPI packages that utilizes the package3 naming strategy > to show python3 compatibility. > And since PuLP (the other pulp) is already py3 compatible I don't see them > wanting the pulp3 namespace. > > If we use this prefix, length won't be a problem: > pip3 install pulp3 > pip3 install pulp3_rpm_extensions > pip3 install pulp3_streamer > > > > On Tue, Apr 11, 2017 at 8:20 AM, Patrick Creech <pcre...@redhat.com> > wrote: > >> After spending the majority of the day hunting down the fine details of >> this plan, I'm in agreement >> with Michael that it isn't the best option here. While it seemed >> interesting on the surface, the >> devil is in the details, as they say. And this just appears to be a >> little too non-standard for us. >> >> Patrick >> >> On Mon, 2017-04-10 at 16:49 -0400, Michael Hrivnak wrote: >> > 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. >> > >> > 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. >> > >> > 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. >> > >> > 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". >> > >> > And if we use a different namespace than "pulp", I don't think we gain >> anything from installing to >> > a separate location. >> > >> > 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. >> > >> > Thanks Patrick for raising this as an option. >> > >> > Michael >> > >> > -- >> > Michael Hrivnak >> > Principal Software Engineer, RHCE >> > Red Hat >> > _______________________________________________ >> > 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 > >
_______________________________________________ Pulp-dev mailing list Pulp-dev@redhat.com https://www.redhat.com/mailman/listinfo/pulp-dev