Document why there is a fork and why catchlog is better

[thedrow]

Yes please. I was wondering the same.

[eisensheng]

Maybe I could gather some arguments and you could tell me if they are good enough to be documented:

• Dead upstream. I can offer to review and merge open PR every weekend or at least every other weekend. The original project has some PR laying around for far too long.
• Evolved feature set and bug fixes. Easier comparison to logged values 1c10253fb3c8d40c96600ec71363e7f8be3ad1c6 for example and a fix to the broken --nocapturelogs option 19ff0645a910a0a7d545e7e0baf7eed350ddb93c

[The-Compiler]

Adding this here as it seems to be related: We discussed at EuroPython if we should add catchlog/capturelog-like functionality to pytest itself. Another possibility would be to move catchlog under the @pytest-dev organization to make sure someone could easily continue maintaining it if @eisensheng isn't able/willing to do so anymore.

See https://github.com/pytest-dev/pytest/issues/946 for some proposals.

[eisensheng]

I'm also all fine with moving the repository under the pytest-dev organization and handing over the maintenance to a broader community. Like I said I'm all in for accepting merge requests and this promise was made to keep this plugin alive. Moving into the organization seems to be the best option to achieve this goal. Just let me know what I have to do and I'll be glad to cooperate.

[The-Compiler]

Sorry for not coming back to this earlier - it got lost somehow and I was happy with pytest-capturelog until pytest 2.8 came out with deprecated __multicall__ :wink:

So, let's move this under pytest-dev then, if you still agree?

See the necessary steps in the pytest docs. I think you fulfill all the requirements, so the only thing left to do for you is:

• Subscribe to the mailinglist
• Write a mail with a link to the repo and request it to be moved to pytest-dev
• Wait until two people approve (you have my :+1: of course)
• Do the move
• (optionally, but recommended) add some people who'll be able to do PyPI releases in case you'd suddenly disappear (which, of course, we all hope you don't!)

[eisensheng]

Sounds like a plan. I would suggest to follow these instructions once #7 has been merged since it adds a real nice round of features and will also fix the deprecated use of __multicall__.

@abusalimov, if you like and agree, I would also love to have you as a maintainer on this package since you contributed far more to this project compared to what I did.

[abusalimov]

@eisensheng Thanks for the kind offer! Let's wait until I finish #7 and come back to discussing the move.

[eisensheng]

@abusalimov okay, enjoy your vacation! I'll provide a documentation for catchlog once the new API lands in develop.

[The-Compiler]

Now that #7 is merged, I'd say let's do the pytest-dev move and a new release on PyPI? :smile:

[eisensheng]

Now that #7 is merged, I'd say let's do the pytest-dev move and a new release on PyPI? :smile:

Yes, definitely. I got distracted half way during the weekend. I registered on the mailing list so far and will continue the steps later today.

[The-Compiler]

Cool, no hurry! Thanks for taking care of this :smile:

[abusalimov]

@eisensheng Do you plan to release a new version before the move, or after? I'd like to address backward compatibility issues before releasing 2.0, so that one could seamlessly migrate from pytest-capturelog to the new version.

I registered on the mailing list so far and will continue the steps later today.

BTW, I saw some discussion about the plugin name. May be we should consider renaming to "pytest-logging" or something?

[abusalimov]

Oh, and considering releasing to PyPI, I'd suggest to automate it using Travis. Here's how I made it for pytest-travis-fold: abusalimov/pytest-travis-fold@94ab2fd0fd101a60404b995ffb616d94ffde6f5b The secret key for a password most likely is bound to the owner/name of the repository, so that should probably be done after moving to pytest-dev.

[eisensheng]

@eisensheng Do you plan to release a new version before the move, or after? I'd like to address backward compatibility issues before releasing 2.0, so that one could seamlessly migrate from pytest-capturelog to the new version.

If possible I would love to mark the current development state as 1.2 and release it to pypi before the move. This is at least what I planned. If you still have something you would like to have for that 1.2 release then just hand it in and I'll merge it before the release. :smiley:

2.0 will happen after the move though.

BTW, I saw some discussion about the plugin name. May be we should consider renaming to "pytest-logging" or something?

I was about to join the discussion since I already registered to the mailing list. While renaming the plugin pytest-logging makes sense I hoped that we could stay with the name and use a dream catcher or something as a logo.

I would also prefer to not merge with py.test core because at least I prefer the modular plugin system and pulling in what you really need over a monolithic that comes with everything attached. Such a large monolith makes it harder for the user to track what changed.

Oh, and considering releasing to PyPI, I'd suggest to automate it using Travis.

I'll look into it, thanks for the hint!

[abusalimov]

If possible I would love to mark the current development state as 1.2 and release it to pypi before the move. This is at least what I planned.

Good plan :+1: Please, keep it up, I don't have any changesets ready anyway.

[abusalimov]

@eisensheng Now when #11 is merged, is there anything else that prevents us to release v1.2 and upload it to PyPI?

If you don't have enough spare time, maybe I could help you somehow, or @The-Compiler could?

[eisensheng]

Now when #11 is merged, is there anything else that prevents us to release v1.2 and upload it to PyPI?

Nothing in particular, just my poor time management. :wink: I scheduled 2 Hours today to work on it and I guess I'll keep it like that depending on how well it works and complaints from other parties. So I would like to test out designating 2 hours for work on this project every Sunday whenever something pops up and maintain discussions and issues during the week whenever I find the time.

I published the current development state as version 1.2.0 now and uploaded it to the pypi. @abusalimov I would be glad if you could check the repository and the pypi if I embarrassed myself somewhere and did something stupid. The release was automated with a tasks.py script that I keep around. If everything went well this can be used to automate further releases and even can be used in more projects.

I decided against using travis to publish releases on the Pypi. It has a bitter aftertaste in my opinion that I have to provide the password for my PYPI login in a file that is public visible. Even if travis supports to encrypt it. The password is quite long and automatically generated but I still would prefer to keep it secret if possible. It would be nice if the PYPI would support OAuth and allow other services to upload distributions through OAuth authorization.

[abusalimov]

Thank you!

I published the current development state as version 1.2.0 now and uploaded it to the pypi. @abusalimov I would be glad if you could check the repository and the pypi

Looks good to me, except for the tag named without the v prefix, i.e. 1.2.0 instead of v1.2.0.

The release was automated with a tasks.py script that I keep around. If everything went well this can be used to automate further releases and even can be used in more projects.

Looks nice, though I'm used to use git-bump for that. It is quite simple and does roughly the same, except for maintaining the changelog, which, in turn, I've noticed in bumpversion - yet another tool, probably more powerful than git-bump. Anyway, if we're going to use tasks.py, I believe there should be a special tox environment for that (e.g. tasks) specifying the necessary invoke dependence. And I'd also suggest to use Pull Requests for such changes in future, though this is up to you.

I have to provide the password for my PYPI login in a file that is public visible. Even if travis supports to encrypt it.

Well, since no one except the Travis party themselves can actually decrypt that password, I guess this is OK to publish it. I mean, at least for me, of course; this is a matter of personal preferences. OAuth2 tokens would be the ideal solution, obviously, but what can you do? Anyway, once we finally move to pytest-dev and have more people with PyPI release rights (they recommend at least three such person), I could put the password of mine into the .travis.yml.

BTW, what's about the move?

• Subscribe to the mailinglist
• Write a mail with a link to the repo and request it to be moved to pytest-dev
• Wait until two people approve (you have my :+1: of course)
• Do the move
• (optionally, but recommended) add some people who'll be able to do PyPI releases in case you'd suddenly disappear (which, of course, we all hope you don't!)

Are we waiting for more than one person to approve? @The-Compiler @hpk42

[The-Compiler]

So I would like to test out designating 2 hours for work on this project every Sunday whenever something pops up and maintain discussions and issues during the week whenever I find the time.

Awesome! :+1:

I decided against using travis to publish releases on the Pypi. It has a bitter aftertaste in my opinion that I have to provide the password for my PYPI login in a file that is public visible.

You could create a separate PyPI user (say, catchlog-bot or whatever) and use that to do the releases.

However, I'd advise against doing that - IMHO, giving an external service the rights to release your project is a bad thing in itself :wink:. And I don't see any benefits - it's not like you'd do a new release every day, or that it'd be any easier this way than running a script locally.

BTW, what's about the move?

I'm guessing people took the current thread more as a general discussion than as an explicit request for a pytest-dev move - I'll send a follow-up mail to make things clear.

[eisensheng]

Looks good to me, except for the tag named without the v prefix, i.e. 1.2.0 instead of v1.2.0.

I decided to drop the v prefix on a whim after looking at other projects how they handle tagging versions. It appears to me to be the cleaner solution since this will result in Github for example calling the source distribution archive pytest-catchlog-1.2.0.zip. This pattern appears to be more common when I look around. I also decided to include the patch version in the release even if it's zero to keep it more semver conform.

This was poorly executed by me though. I should have asked you guys first before deciding something like this. It's unfamiliar for me to work in a larger group where I can't just decide things on my own so I have to get rid of this habit first. I promise to improve here.

Looks nice, though I'm used to use git-bump for that. It is quite simple and does roughly the same, except for maintaining the changelog, which, in turn, I've noticed in bumpversion - yet another tool, probably more powerful than git-bump.

Never heard of git-bump before and never used bumpversion before. I must admit that I haven't searched for those solutions before and only randomly stumbled over them. I find this topic actually very hard to solve properly. Additional tools to handle these tasks are quiet nice and having other people maintain them is nice so I don't have to shoulder that burden. It's difficult to synchronize many developers on the same tool belt though. It can be incredible difficult and also highers the bar for other developers to join development. This is why I included the tasks.py directly in the repository. It's also a nice spot to further automatize the release process. I realize that this again requires to have Invoke installed. Like I said, I find it incredible difficult to solve properly. I would rather prefer to solve the problem of synching developers on the same tool belt I'm open minded enough to change my stance on this topic though.

Anyway, if we're going to use tasks.py, I believe there should be a special tox environment for that (e.g. tasks) specifying the necessary invoke dependence.

Maybe it would be a good thing to provide development requirements in a separate file all together.

And I'd also suggest to use Pull Requests for such changes in future, though this is up to you.

Again, this was poorly executed by me and I understand that. I promise to improve here.

Well, since no one except the Travis party themselves can actually decrypt that password, I guess this is OK to publish it. I mean, at least for me, of course; this is a matter of personal preferences. OAuth2 tokens would be the ideal solution, obviously, but what can you do? Anyway, once we finally move to pytest-dev and have more people with PyPI release rights (they recommend at least three such person), I could put the password of mine into the .travis.yml.

I share @The-Compiler's opinion here though. I would also like to point out the security concerns here. I find Travis to be incredible useful for running the continuous testing environment. I find it difficult to entrust Travis with administrative tasks though. Given the nature of what Travis does it executes a lot of foreign and untrusted code. It speaks for the developers of Travis that they haven't suffered a single breach yet. I'm impressed and they deserve more kudos for this. They can't guarantee it will stay to be like this though. Neither can I guarantee that I would suffer from a security breach, I understand that much. Then again given the nature of what they are doing and how many other developers are entrusting them with administrative tasks I would say they're way more interesting as a target then I am. I just don't want to be part of it if or when it happens.

If you still insist on using Travis for automating the release process, then I would suggest to at least use a separate release bot account like @The-Compiler suggested.

BTW, what's about the move?

I'm guessing people took the current thread more as a general discussion than as an explicit request for a pytest-dev move - I'll send a follow-up mail to make things clear.

I hoped that the outcome of the current discussion would be whenever they want to merge the functionality directly into pytest or not. It would be pointless to ask for inclusion into the pytest organization if the former is still the case. But the discussion came to an halt it seems. Maybe I should just submit the request for the inclusion in a new thread.

[The-Compiler]

I don't think the v prefix is a big deal - I've seen plenty of projects with and without it.

As for releasing, I don't think the exact workflow matters - what's important is that it's documented how to do a proper release, like HOWTORELEASE.rst for pytest core.

If pytest-catchlog gets merged into core, I'm guessing that'd be more of a long-time thing (8 months between pytest 2.7 and 2.8, for example) - and I think at least you and I both think it's not a good idea. So I think moving it to pytest-dev is a good idea regardless.

I already did start a new thread for the move: https://mail.python.org/pipermail/pytest-dev/2015-November/thread.html

Unfortunately it seems there's also an unrelated pytest-logging to increase the confusion... I opened an issue asking if it would make sense to merge that into catchlog: https://github.com/saltstack/pytest-logging/issues/1

[abusalimov]

Looks good to me, except for the tag named without the v prefix, i.e. 1.2.0 instead of v1.2.0.

I decided to drop the v prefix on a whim after looking at other projects how they handle tagging versions.It appears to me to be the cleaner solution since this will result in Github for example calling the source distribution archive pytest-catchlog-1.2.0.zip.

Well, Pro Git uses v in examples. And it is just what GitHub suggests when creating a tag through the web interface:

Tagging suggestions

It’s common practice to prefix your version names with the letter v. Some good tag names might be v1.0 or v2.3.4.

They will also drop the v letter in the name of a source archive, so you'll get pytest-catchlog-1.2.0.zip anyway.

This pattern appears to be more common when I look around.

Yeah, at least pytest-core sticks to that, you're right.

I also decided to include the patch version in the release even if it's zero to keep it more semver conform.

This is :+1: from me, undoubtedly.

Well, I guess, this is again a matter of taste. Probably I'm just used to that schema.

[The-Compiler]

Since the pytest-catchlog plugin was merged into the pytest core, this probably isn't applicable anymore.