Re: Bug#819681: RFS: python-django-gravatar2/1.4.0-1 [ITP]
Le jeudi 07 avril 2016 à 17:45:27-0300, Tiago Ilieve a écrit :
> Pierre-Elliott,
>
> On 7 April 2016 at 12:27, Pierre-Elliott Bécue <becue@crans.org> wrote:
> > You're right, but I'm an "explicit is better than implicit guy". :)
>
> I guess this is not a case of "explicit vs. implicit". Imagine the
> entire line as an URL:
>
> https://github.com/P-EB/python-django-gravatar2.git%20-b%20master
>
> Of course you wouldn't have a problem if you copy-and-pasted it
> (before escaping the spaces) on the command line, as the "-b master"
> would be interpreted as arguments to "git clone". But, if you copy and
> pasted on another client, e.g. a GUI Git client (which I've seen
> people using), the URL may be interpreted like above (after escaping)
> and the cloning process will fail.
>
> Not to mention that this is expected to be in machine-readable form,
> which may not be aware that someone is passing Git command line
> arguments along the URL.
In that case, if the main branch wasn't `master` the issue would be the
same, yet you'd need the `-b` option. That's my view of explicit V.S.
implicit, you'd have something working based on an assumed behaviour.
> > I thought it'd be better to keep them, but, okay.
>
> They are mostly related to building projects written in C, so there's
> little use for a pure-Python one, as you are not "saving them for
> later".
Yeah, I agree.
> > I'm not in fond of PYBUILD_NAME thing since I met a lot of trouble with it.
> > If that's recommended I'll put it but I'm more a ".install" files guy.
>
> Imagine that you would be doing by hand what is expected to be
> automated by Pybuild.
Actually, truth is when I answered to you I forgot one main reason I
switched to .install files : this variable was messing with my package
mailman3-core{,-doc}, which name didn't contain python/python3 in front. So
I thought this variable was more an issue that a help, but for a library, it
works fine, so I can use it directly and avoid .install files.
> > I do not have any issue to build multiple times, but I'll follow your
> > advice.
>
> Are you building with pbuilder or something like that? I've used
> dpkg-buildpackage and it complained in the second time I ran it.
sbuild.
> > I'm really uncomfortable with tests un packaging for python apps, but I can
> > try to remove the override. Anyway, I'm using pybuild, hence the pypi
> > package fits better and a good way to have a snapshot of upstream's work.
>
> Why uncomfortable with tests in packaging? They can help to make sure
> that newer versions aren't introducing regressions.
My first packages didn't contain any tests. The first one with tests I had
was mailman3-core, which needs for the tests running a basic mailman3 server
installed, this is not really compatible with the way the tests are done in
packaging.
This one is a django library, that requires settings to be installed. Same
issue.
I tried to deal with these, but it's really painful. So either there is a
way for django packages to do it properly or I'd rather not do the test part
in the packaging process.
> I didn't understood why PyPI packages would fit better than snapshots
> (tarball releases) from the upstream repository.
It allows to check for updates in an easier way and I don't see any benefit
in taking sources from upstream page instead of using pypi.
> On 7 April 2016 at 12:51, Pierre-Elliott Bécue <becue@crans.org> wrote:
> > I uploaded a new version of the package. It should be visible soon, and
> > accessible also via
> >
> > dget -x http://mentors.debian.net/debian/pool/main/p/python-django-gravatar2/python-django-gravatar2_1.4.0-2.dsc
>
> You shouldn't bump the version of the package yet, as it was never
> uploaded to the archive. Until the first upload, it will be "X.Y.Z-1",
> no matter how many changes you did to it. Then you can bump the
> version in the following revisions, but only after every upload, not
> after every change in the packaging work.
When I tried to dput I've been refused it because 1.4.0-1 was already on the
server. That's the only way I found. Maybe I did something wrong.
> P.s.: I've seen that you pushed changes with "--force" to the Git
> repository. Please don't do that when you already shared it with other
> people. They will not be able to merge/pull easily (as there are
> annoying merge conflicts in the changed files) and will be harder to
> analyze what you really did (which is the primary feature of every
> version control system), as there will be no visible difference in the
> history.
Yeah, that was to have a clean history, but I admit this practice is rude.
I'll definitely avoid it.
--
PE
Reply to: