[Pulp-dev] PyPI names for Pulp3

[Bihan Zhang]

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 <pcreech at 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 at redhat.com
> > https://www.redhat.com/mailman/listinfo/pulp-dev
>
> _______________________________________________
> Pulp-dev mailing list
> Pulp-dev at redhat.com
> https://www.redhat.com/mailman/listinfo/pulp-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/pulp-dev/attachments/20170411/c6c422f9/attachment.htm>