I would prefer pulp3 over pulpproj, nice idea Bihan! On Wed, Apr 12, 2017 at 1:47 AM, Dennis Kliban <dkli...@redhat.com> wrote:
> 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 > >
_______________________________________________ Pulp-dev mailing list Pulp-dev@redhat.com https://www.redhat.com/mailman/listinfo/pulp-dev
