[Pulp-dev] PyPI names for Pulp3

[Austin Macdonald]

+1 for the pcreech {datadir} plan.

If we go with the pcreech plan, I am -0 on using `pulpproj` for our PyPI
name. If we are not using the PyPI name at import time, then the length
problem [0] no longer exists, and we are abbreviating without a good
reason. I think "pulpproject" would be best, since it matches our website.
We want our users to have to remember as little as possible.

[0]: https://pulp.plan.io/issues/2444#note-8

On Mon, Apr 10, 2017 at 11:45 AM, Brian Bouterse <bbouters at redhat.com>
wrote:

> After considering @pcreech's point, +1 installing Pulp in {datadir} and
> having it install there using setup.cfg options. In terms of setting the
> PYTHONPATH at runtime, it would be best if we could have the Python code do
> it itself at startup. As an alternative we could do it with the systemd
> units, but then on other distros they would have to figure it out all again
> so by doing it in the processes themselves we would avoid that.
>
> We still need to pick the PyPI names we would distribute with, but this
> would allow us to have all imports be:
>
> from pulp import ....
>
> or for plugins
>
> from pulp_rpm import .....
>
> -Brian
>
> On Fri, Apr 7, 2017 at 5:59 PM, Patrick Creech <pcreech at redhat.com> wrote:
>
>> I've been doing some preliminary research into a 'Have our cake and eat
>> it too' option.
>>
>> While getting back up to speed on things pulp, I came across this comment
>> on the FPC ticket:
>>
>>     https://pagure.io/packaging-committee/issue/671#comment-146777
>>
>> Buried towards the end of this comment, in the second to last paragraph,
>> is a statement of interest
>> from a packaging perspective:
>>
>>     "Moving the common library out of %{site_packages}/pulp and into, for
>> instance,
>> %{_datadir}/pulp_common/pulp will also fix the conflict".
>>
>> Something to consider, our Pulp project is not intended to be a general
>> purpose system library.  It
>> is for pulp purposes only (and pulp plugins).  With that, we don't
>> necessarily need to live in site-
>> packages.  FWIW, we do something similar with the SCL that was created.
>>
>> We will have to modify pulp tooling to either set PYTHONPATH (bash
>> script) or sys.path (python
>> script), but this allows us to keep 'import pulp' while preventing
>> conflicts with the PuLP project.
>> This also addresses the Fedora package collision by moving our files out
>> of site-packages as well,
>> removing the RPM file collision.
>>
>> After doing some reading on setuptools, we can specify "setup.py install"
>> options in setup.cfg,
>> allowing us to do this across various ways of distributing our software.
>>
>> The last piece is how pypi will treat this (as it was expressed to me
>> that pip install pulp_project
>> is of interest).  My initial reading seems to suggest this as 'just
>> works' with the setup.cfg, but I
>> would like to verify this.
>>
>> Thoughts?
>>
>> Patrick
>>
>>
>> _______________________________________________
>> 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/20170410/98fa51f5/attachment.htm>