Re: [Pulp-dev] Proposal to use google style docstrings (PUP-2)
I left many comments. Mostly language and clarification requests. Since there are so many comments the pull request is a bit unreadable. FYI, you can see a rendered version of the current state here: https://github.com/asmacdo/pups/blob/google-docstrings/pup-0002.md Thanks @asmacdo for leading this. -Brian On Mon, Apr 10, 2017 at 2:14 PM, Austin Macdonald wrote: > PUP 2 [0] is still getting feedback and changing, so we are extending the > vote to April 12 at 9pm UTC [1]. Voting procedure is described in PUP 1. [2] > > Comments, nitpicks, and votes are welcome from anyone who is interested! > > [0] - https://github.com/pulp/pups/pull/2 > [1] - http://bit.ly/2oXOREo > [2] - https://github.com/pulp/pups/blob/master/pup-0001.md#voting > > ___ > 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
Re: [Pulp-dev] PyPI names for Pulp3
"pulpproj" has grown on me. For a while I was fond of something like "pulp_app", thinking as both a django app and celery app. Then we'd have "pulp_streamer", "pulp_common", and "pulp_cli" all as top-level namespaces. I still think this would be a fine approach, but I lean in favor of keeping our current pattern and just replacing "pulp" with "pulpproj". Michael On Fri, Apr 7, 2017 at 2:54 PM, Brian Bouterse wrote: > Pulp3 can't use the 'pulp' Python namespace like we did on Pulp2 because > it's already taken on PyPI and we don't want to conflict. We need to decide > on some new Python package names. > > I've updated a previous write-up[0] with options we have in this area. It > talks about package name options for pip installing purposes, and it > discusses how we will lay out the packages within site-packages. > > I prefer the prefix of 'pulpproj' with "idea 2". I also prefer all > packages will install under a top level dir. So that would cause platform > to pip install with: > > pip install pulpproj > pip install pulpproj_cli > pip install pulpproj_streamer > > All of ^ packages would be laid out on the filesystem as: > > /usr/lib/python3.5/site-packages/pulpproj/ > ├── cli > ├── common > ├── platform > └── streamer > > What are your thoughts and ideas? What do you prefer? Also should this > become a PUP? > > [0]: https://pulp.plan.io/issues/2444#note-7 > > -Brian > > ___ > Pulp-dev mailing list > Pulp-dev@redhat.com > https://www.redhat.com/mailman/listinfo/pulp-dev > > -- Michael Hrivnak Principal Software Engineer, RHCE Red Hat ___ Pulp-dev mailing list Pulp-dev@redhat.com https://www.redhat.com/mailman/listinfo/pulp-dev
Re: [Pulp-dev] PyPI names for Pulp3
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
On Mon, Apr 10, 2017 at 3:58 PM, Austin Macdonald
wrote:
> +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
> 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
>> 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@redhat.com
>>> https://www.redhat.com/mailman/listinfo/pulp-dev
>>>
>>>
>>
>> ___
>>
Re: [Pulp-dev] PyPI names for Pulp3
+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
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 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@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] Call for Presenters: Sprint 17 Demo, Thursday April 13
The Sprint 17 demo is scheduled for Thursday April 13 at 14:00 UTC [0]. If you've done any of the following as part of Sprint 17, please consider signing up as a presenter [1]. - Notable feature - Notable bugfix - QE update/activity This sprint demo will be a live community event. Please sign up soon so I can advertise to users by Wednesday at the latest. [1]: http://bit.ly/2oRMmUy [0]: https://etherpad.net/p/Pulp_Sprint_Demo_Agenda Thanks, Brian ___ Pulp-dev mailing list Pulp-dev@redhat.com https://www.redhat.com/mailman/listinfo/pulp-dev
Re: [Pulp-dev] Proposal to use google style docstrings (PUP-2)
PUP 2 [0] is still getting feedback and changing, so we are extending the vote to April 12 at 9pm UTC [1]. Voting procedure is described in PUP 1. [2] Comments, nitpicks, and votes are welcome from anyone who is interested! [0] - https://github.com/pulp/pups/pull/2 [1] - http://bit.ly/2oXOREo [2] - https://github.com/pulp/pups/blob/master/pup-0001.md#voting ___ Pulp-dev mailing list Pulp-dev@redhat.com https://www.redhat.com/mailman/listinfo/pulp-dev
Re: [Pulp-dev] PyPI names for Pulp3
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 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@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
