Gain access to pypi and automate releases using travis

[knoppo]

travis can be used to automatically push a new release to pypi for each new git tag.

https://docs.travis-ci.com/user/deployment/pypi/

I think the best way would be to get access to the pypi account, otherwise the pypi guys need to be contacted to transfer the repository. This needs to be done anyway if the current maintainer uses the account for other packages, too.

Also for maintainability reasons, maybe more than one active collaborator should have access to the pypi account?

[knoppo]

#15 @bwesterb The current pypi release
#29 @lucc mentioned this

[pazz]

This sounds a bit overkill to me. Sure, someone (not me) needs to update pypi after releases in order to keep that up to date (if we want that). But this does not happen very often. Also, It looks kile this requires us to publish the pypi credentials in plaintext in the .travis.yml file? Not convinced.

Anyway, there are not too many active developers in any case, because development is not really active on this project. I tried to get it merged on mainstream urwid a couple of times, but the main dev there seems not interested enough to put in the extra effort..

[knoppo]

Yes, nobody wants to do it. Thats the reason why I think this is a good choice even if theres not much development. No, the password will be encrypted (next paragraph in the link).

It seems to me there are more and more projects depending on urwidtrees.

I thinks its totally fine to have urwidtrees as an optional package.

[pazz]

Quoting Mathias Stelzer (2016-12-27 16:47:00)

Yes, nobody wants to do it. Thats the reason why I think this is a good choice even if theres not much development. No, the password will be encrypted (next paragraph in the link).

Ah I see. In that case I could warm to it. Do you want to set this up and send a PR?

It seems to me there are more and more projects depending on urwidtrees.

really? cool! got some links?

I thinks its totally fine to have urwidtrees as an optional package.

sure. Getting it merged into mainline urwid would have been one way for me to get rid of the responsibility :)

[knoppo]

Sure thing, I'll do that! If @bwesterb does not answer in some time I'll try to get access to the pypi repository.

I don't know other actual projects, yet. But recent PR's, Tickets and Stars indicate a growing userbase, don't they?
I'm currently working on this https://rolln.de/knoppo/hogi. It makes heavy use of urwidtrees ;)

[bwesterb]

I'm happy to upload a new version of urwidtrees to pypi once in a while. (That was the deal – but I didn't get a notification that there was a new version.) But if @pazz likes to do it himself now – that's fine: I can transfer the pypi repository. There doesn't seem to be any functional change between 1.0.1 and 1.0.2 except for 1da928f, right?

[knoppo]

In that case its up to @pazz i guess. I'd prefer the automation so no one has to care about it anymore, but if you're fine with updating it once in a while I don't want to stop you :)

Yes I think it would be awesome to have 1.0.2 ( or even 1.0.3.dev / 1.0.3 ) in pypi.

[pazz]

@bwesterb you are right, there has been no functional chance recently and there also hasn't been a release since 1.0.2.
The reason why i tagged version 1.0 was that I considered this project done. More recent versions were/are for bugfixes and cleanups. I don't expect any major changes from now on, so that's why I think there is no real need for automated pypi packaging. If you are still fine with being responsible for upcoming pypi releases, then we're settled :)

[knoppo]

I created #38 to improve the pypi page for urwidtrees. @bwesterb It should be merged before the next release :)

@pazz What do you think about showing pip install urwidtrees in the readme/docs again? What was the reason to remove it?

[bwesterb]

@pazz Shall I release the current master as 1.0.3?

[pazz]

Quoting Bas Westerbaan (2016-12-28 10:45:28)

***@***.*** Shall I release the current master as 1.0.3?

Let's wait some more, see if some more cleanups come in (I recently activated an automated code-nazi that could motivate some of us to submit easy stuff). When I tag the next release I'll let you know, thanks.

[bwesterb]

Ok!

[lucc]

@pazz I assume by "code nazi" you mean quantifiedcode. If so:

1. the staticmethod suggestion is not helpful as these methods seem to be dummys that will be overwritten
2. All but one of the consecutife ifs are false positives in my opinion (as there are "else" cases for the outer if)
3. the classes need not really be documented
4. the functions are best documented by the author (you :)

[pazz]

@lucc yes, I agree. thanks for having a look anyway.
If you find the time, please have a look at and comment on #33.
Otherwise, I'm fine with tagging version 1.0.3 and letting s/o push it to pip

[pazz]

I have just tagged 1.0.3.
@bwesterb If you are still in command of the pypi package, please update.
I am aware that github actions can now be used to directly update pypi when making releases. If s/o has experience with this and can tell me how to set it up I'd gladly do so.

[bwesterb]

I will have access to my login tomorrow evening. Will do it then. Sorry for the delay.

[bwesterb]

Done.