Re: Bug#819681: RFS: python-django-gravatar2/1.4.0-1 [ITP]
Hi Pierre-Elliott,
On 11 April 2016 at 14:05, Pierre-Elliott Bécue <becue@crans.org> wrote:
> 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.
There's no issue, as the repository from which you are cloning from
has the information about what the default branch is. This has been
discussed here a couple weeks ago[1][2].
> 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 see. But mailman3 is a much more complex package, isn't it? I prefer
to start choosing simplicity and only picking any needed workarounds
later.
> sbuild.
Interesting. I've never used it and tend to use chroot-based
approaches only to make sure the package isn't suffering from FTBFS
issues. On a daily basis I use dpkg-buildpackage inside a VM or
container (been using Docker for this lately) with sid/unstable.
> 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.
I'm not sure if DEP-8 tests can run daemons, but you can take a look
at Debian CI[3]. Maybe it helps you in this matter.
> 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've been a Django developer for a couple years in the past, but
shamefully I'm not (and wasn't at the time) well-versed in testing
libraries for it. Not being able to help you with that, I'd suggest
you to ask about it on "debian-python" mailing list if you like.
> 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.
You can easily check for new releases on GitHub[4] as well.
The issue here is that they aren't exactly the same. I've download
tarballs from both of them and diff'ed the two directories:
Common subdirectories: github-django-gravatar-1.4.0/django_gravatar
and pypi-django-gravatar2-1.4.0/django_gravatar
Only in pypi-django-gravatar2-1.4.0/: django_gravatar2.egg-info
Only in github-django-gravatar-1.4.0/: example_project
Only in github-django-gravatar-1.4.0/: .gitignore
Only in pypi-django-gravatar2-1.4.0/: PKG-INFO
Only in github-django-gravatar-1.4.0/: RELEASING.rst
Only in github-django-gravatar-1.4.0/: requirements.txt
diff github-django-gravatar-1.4.0/setup.cfg
pypi-django-gravatar2-1.4.0/setup.cfg
2a3,8
>
> [egg_info]
> tag_build =
> tag_date = 0
> tag_svn_revision = 0
>
Only in github-django-gravatar-1.4.0/: tox.ini
Only in github-django-gravatar-1.4.0/: .travis.yml
As you see, files like "tox.ini", which could help you to run the
tests, are missing from PyPI. There's not really a problem in
packaging anything from PyPI, but I guess that's no better place to
fetch release tarballs if they come straight from the upstream
repository, right?
> 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.
Maybe you uploaded again before mentors.d.n processed the first
upload? There's an waiting time ("How long will it take until my
upload is available to sponsors?" from its Q&A[5]) between the upload
and the package actually being available in there. I'm suggesting this
because mentors.d.n even store different versions of the package, even
when you did not bump its version. You can always use the delete
button from its web interface as well.
> Yeah, that was to have a clean history, but I admit this practice is rude.
> I'll definitely avoid it.
Thanks for considering my request about this. I appreciate.
Regards,
Tiago.
[1]: https://lists.debian.org/debian-mentors/2016/04/msg00057.html
[2]: https://lists.debian.org/debian-mentors/2016/04/msg00060.html
[3]: https://ci.debian.net/doc/
[4]: https://github.com/twaddington/django-gravatar/releases
[5]: http://mentors.debian.net/qa
--
Tiago "Myhro" Ilieve
Blog: https://blog.myhro.info/
GitHub: https://github.com/myhro
LinkedIn: https://br.linkedin.com/in/myhro
Montes Claros - MG, Brasil
Reply to: