Release on PyPI & naming conflict

[zerok]

Hi :)

Is there any roadmap for releasing this on PyPI and potentially renaming this project?

Right now pip-installing django-backup will install https://github.com/chriscohoat/django-backup, which hasn't been updated in quite a while and doesn't support media backups among other things.

It doesn't really help that this repo here has a higher rank on Google and DuckDuckGo than the other repo or the PyPI entry which leads to even more confusion when doing the eventual pip install django-backup ;-)

[andybak]

Hi. I didn't actually know anyone else was using this!

I'll email Chris Cohoat and see if he's happy to relinquish control of the original name - if not then I'm happy to rename this fork. Ping me an email and I'll cc you in.

[zerok]

Hi :)

I'm not (yet) using it but I stumbled over django-backup and really liked that you combined backing up the database and the media folders into one command instead of two as it is done in django-dbbackup, for instance :-)

What I mentioned above just simple prevented me from giving it a proper go and I was surprised that a package that has been maintained for so long hasn't yet found its way onto PyPI :-)

[andybak]

Hi,

Chris has kindly added me as an owner on PyPi and I've created a canonical repo to act as the home: https://github.com/django-backup/django-backup

I think we have to be careful about breaking backwards compatibility so I propose we keep 1.x exactly as it was and then switch to my code as the 2.x release.

I'm not terribly experienced with pkg and setup.py stuff - do you fancy helping out? :-)

[zerok]

Awesome! Thank you both :-)

I will try to find some time this week (long train rides, vacation...) to look over the setup.py and perhaps add some automated tests then :-)

[andybak]

Great! I'll add you to the Github org.

What's the best way to do this? Shall I reinit the repo as a 100% clone of Chris's and then merge in my version as the starting point for v2.x?

[zerok]

Thank you, although I'm not sure how I much I will be able to contribute :-)

Good question. The two don't have a common history, right? If so, I'd just extend the readme with a notice that v1 can be found in Chris' repository.

[andybak]

They do have a common history but it's quite a long way back.

We don't want to break things for anyone who currently pip installs django-backup with a sensible version string.

i.e.

django-backup<2.0

or

django-backup==1.1

If someone hasn't specified a version then sadly we can be excused for breaking things. So I reckon if we start from Chris's version, bump the version to 2.0 and import the latest code from my branch then we should be safe.

The repo I imported is my branch so I should delete that and clone Chris's instead. Sound sensible?

[zerok]

Sounds good :-) Next thing is that perhaps your ftp-library fork should become an optional dependency. I, for instance, don't want the backup to pushed anywhere but another server to pull it. For this scenario I don't need an additional libraries :-)

[andybak]

Yep. I notice we're not actually specifying our requirements so at the moment it's about fixing import and the docs.

However we can add requirements and pip will handle them automatically even with optional extras. A user could write this in their own requirements.txt:

django-backup[ftp]

And we'd need something like this in setup.py:

extras_require = {
    'ftp':  ['pysftp'],
}

I don't think I'm using ftp myself any more. We switched to rsync for both db and media files if I recall correctly.

[zerok]

Doesn't this still depend on your own fork of that library? If so I'm wondering if it wouldn't be a good idea to drop FTP support completely for the first 2.0 release and perhaps reintroduce it later on if people absolutely need it and the dependency situation is a bit clearer.

[andybak]

Hmmm. So maybe move the import statement into a block that only runs if ftp is used? And clarify the readme?

[zerok]

And ideally hide the commandline options as well :-/