[Pulp-dev] PyPI names for Pulp3

[Daniel Alley]

I would prefer pulp3 over pulpproj, nice idea Bihan!

On Wed, Apr 12, 2017 at 1:47 AM, Dennis Kliban <dkliban at redhat.com> wrote:

> 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
>>
>>
>
> _______________________________________________
> 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/f7264cd1/attachment.htm>