[Pulp-dev] PyPI names for Pulp3

[Dennis Kliban]

I like using the pulp3 namespace.

On Tue, Apr 11, 2017 at 9:13 AM, Bihan Zhang <bizhang at 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 <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
>>
>>
>
> _______________________________________________
> 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/20170412/42410381/attachment.htm>