Fixed via commit 2b5388230fb39dff85e3522db753d20e8c88dfab.

I figured that was in the other repo. I probably move an empty line with the IDE unconsciously. This is now fixed.

This looks like a mistake stemming from the adaption of the f-strings in the Python script. :hankey:

• Update to base image to the current latest ModuleSync
• Expands the setup examples to show how automatic MRs / PRs are configured.

NOTE: This PR must be merged after https://github.com/vshn/docker-modulesync/pull/9 is merged, and the new Docker images were published successfully on Docker Hub.

This will generate new Docker image( tag)s for the newer modulesync versions v1.1.0 through v1.3.0.

PR #56 was closed by request of the PR and issue author. Is there a proper way to get this topic resolved? Maybe add an explanation of the behavior to the related docs?

We should otherwise close this issue.

With our test setup in this project we use "decorators" in the .feature files, and selectively run the related tests using behave's --tags option.

Does that already answer your question?

For some reason, the tests that cover fixture loading specify a @requires-live-http decorator.

@sebastianmanger, @mixxorz, does one of you happen to remember why?

I'm not sure why using --simple should result in a different behavior with fixtures. For what I understand from the documentation and source code there should be no reason why fixtures aren't loaded.

Related resources:

• Django 3.0 source code
• Official documentation on TestCase
• Official documentation on Fixture loading
• Our test case adaption

Were you able to understand more? Would you be able to add a test case that mimics the behavior?

That one has popped up a few times since it was introduced with #46. Should be fixed now with commit 4d8df68. Sorry for the inconvenience. Not sure why this happened since not even the tests show the second argument.

Can you check the updated documentation and close this issue if the change is fine?

This PR contains the following updates:

Release Notes

<details> <summary>getsentry/sentry-python</summary>

v0.16.3

Compare Source

• Fix AWS Lambda support for Python 3.8.
• The AWS Lambda integration now captures initialization/import errors for Python 3.
• The AWS Lambda integration now supports an option to warn about functions likely to time out.
• Testing for RQ 1.5
• Flip default of traceparent_v2. This change should have zero impact. The flag will be removed in 0.17.
• Fix compatibility bug with Django 3.1.

</details>

Renovate configuration

:date: Schedule: At any time (no schedule defined).

:vertical_traffic_light: Automerge: Disabled by config. Please merge this manually once you are satisfied.

:recycle: Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.

:no_bell: Ignore: Close this PR and you won't be reminded about this update again.

• [ ] <!-- rebase-check -->If you want to rebase/retry this PR, check this box

This PR has been generated by WhiteSource Renovate. View repository job log here.

Awesome! :astonished: :smiley:

With those changes the code looks much nicer.

Maybe you want to add a similar change to the edit links? Not all sections seem to allow editing, though. I'm not sure why.

That's correct, there is only a single branch here. I mixed this up with the modsecurity-docker repository. Sorry!

@shiz0 Can you squash all your changes into a single commit in the end, please?

Good that we didn't merge this yet.

The original idea was that we have a single source of truth for the Dockerfile and its related configuration, which should ideally live in the src folder, and there should be a Makefile (or something similar) to (re)generate the Dockerfiles for all the currently supported CRS versions and web proxy combinations.

This was originally described in https://github.com/coreruleset/modsecurity-docker/issues/32 and related issues. Looks like we missed out on implementing this to the full extend, as originally planned.

What Next?

We could

• either merge this PR "as is", and attempt the scripted implementation of generating all Dockerfile setups as a follow-up step
• or you could try to implement the scripted approach with this PR directly, before merging it into master.

Opinions?

(Personally, I'd prefer to add another commit with the scripted generation to this PR, already. This would make sure the job gets done more likely, I believe. Just a personal opinion, though.)

It's probably a good idea to update the reference to the latest development branch, e.g.

# https://github.com/coreruleset/coreruleset/blob/v3.4/dev/rules/REQUEST-900-EXCLUSION-RULES-BEFORE-CRS.conf.example

Though, this change would be totally optional. This file is only used in docker-compose.yml, IIUC.

Same, optional change here:

# https://github.com/coreruleset/coreruleset/blob/v3.4/dev/rules/RESPONSE-999-EXCLUSION-RULES-AFTER-CRS.conf.example

The project has quite a few section types, which all seem to have a "Add new section" link at the end of a section to allow adding new items. The related code is duplicated all over the templates (e.g. degrees, books, articles, grants, students, talks).

Instead of duplicating code, a template tag shall implement the internals and the templates shall call the template tag with appropriate parameters. Similar for editing existing items.

The package documentation describes:

• how to install the package, run the migrations and how to extend urls.py to make API endpoints available
• how to run tests and how to contribute

What is missing is a description of the actual features, e.g.

• What does the package do?
• How can users benefit?

The "Features" section from the README, which is included in the docs still bears a big "TODO" notice.

The repository was moved only recently. You can expect most if not all absolute URLs to point to the "wrong" location. If you want to try a PR to fix the situation that would be helpful. Only the master branch is relevant, you can ignore all other branches.

The README on Docker Hub is not updated automatically since we build the images with GitHub Actions and don't let Docker Hub take care of it. That needs to be updated manually. Thanks for reporting!

I can't comment properly now as I'm on the beach, currently. 🏖️ However, I encourage you to find out and find an intuitive, the most intuitive way, ideally.

Just a comment on your history, my personal preference would be to integrate pytest style testing into behave, or at least behave-django. See https://github.com/behave-contrib/behave-pytest/issues/1 for example.

I've also recently added page objects to allow for a clean approach on BDD testing typical websites.

Whatever helps to make testing easy, intuitive, straightforward, yet still keeping a clean approach, let's make it come true if it's not possible yet.

This PR contains the following updates:

Release Notes

<details> <summary>urllib3/urllib3</summary>

v1.25.10

Compare Source

Release: 1.25.10

</details>

Renovate configuration

:date: Schedule: At any time (no schedule defined).

:vertical_traffic_light: Automerge: Disabled by config. Please merge this manually once you are satisfied.

:recycle: Rebasing: Renovate will not automatically rebase this PR, because other commits have been found.

:no_bell: Ignore: Close this PR and you won't be reminded about this update again.

• [ ] <!-- rebase-check -->If you want to rebase/retry this PR, check this box

This PR has been generated by WhiteSource Renovate. View repository job log here.

The change should keep the indenting intact.

urllib3==1.25.10          # via sentry-sdk{% endif %}

This PR contains the following updates:

Release Notes

<details> <summary>getsentry/sentry-python</summary>

v0.16.2

Compare Source

• New (optional) integrations for richer stacktraces: pure_eval for additional variables, executing for better function names.

v0.16.1

Compare Source

• Flask integration: Fix a bug that prevented custom tags from being attached to transactions.

</details>

Renovate configuration

:date: Schedule: At any time (no schedule defined).

:vertical_traffic_light: Automerge: Disabled by config. Please merge this manually once you are satisfied.

:recycle: Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.

:no_bell: Ignore: Close this PR and you won't be reminded about this update again.

• [ ] <!-- rebase-check -->If you want to rebase/retry this PR, check this box

This PR has been generated by WhiteSource Renovate. View repository job log here.

• Kustomize is reported to have a new --from-file option of the edit command
• SOPS has new --recursive and --omit-extensions flags

It looks like there is no button anymore, or none with a class="l-accept__btn" attribute on the page being evaluated. Or the page did load too slowly.

I have released v2.0.0, which should now work on any platform supported by Python3.

Can you try whether it does what you expect?

python3 -m pip install --upgrade pyclean

pyclean --version
2.0.0

pyclean --help

I have released v2.0.0, which should now work on any platform supported by Python3.

Can you try whether it does what you expect?

I have released v2.0.0, which should now work on any platform supported by Python3.

Can you try whether it does what you expect?

The lack of cross-platform compatibility seems rooted mainly in the dependency on debpython:

ImportError: No module named debpython

Related

• Example of failing build (AppVeyor)
• python-defaults > debpython (source code)
• python3-defaults > debpython (source code)

I will go a different route: Instead of trying to make the Debian scripts behave well on other platforms there will be the modern, pure python implementation that will try to come close to Debian's feature set for cleaning up byte code.

I say "try", because there are no tests available for the Debian scripts, which makes it difficult to prove that the implementations match. I'll be dependent on feedback from the original maintainers.

I have released v2.0.0, which should now work on any platform supported by Python3.

@HoECoder @rittneje Can you try whether it does what you expect?

C:\your\code\folder> python3 -m pip install --upgrade pyclean

C:\your\code\folder> pyclean --version
2.0.0

C:\your\code\folder> pyclean .

You can also use the --dry-run and --verbose options to help you understand what the command is doing.

See the usage screen for details:

C:\your\code\folder> pyclean --help

@taharushain Flake8 complains that 3 lines are too long. Please split up the lines to make Flake8 happy.

Can you re-evaluate the current behavior? I believe it is already in sync with the oc CLI. There should be no need for a change.

Implements the modern, pure Python and Python 3 only bytecode files and folders cleanup.

Allows to specify target directories only, for the moment (no packages and the like).

Here is the explanation of the "for some reason":

• Code should be self-explanatory (no comments should be needed that explain what the code does, unless they explain a concept or approach)
• Test code should be obvious and easy to read (if test code is difficult to understand there is risk that the test code doesn't do what you intended; and who can easily prove without tests?)

The simpler a test is, the better.

Implements the modern, pure Python and Python 3 only bytecode files and folders cleanup.

Allows to specify target directories only, for the moment (no packages and the like).

I managed to flawlessly install the extension in my shiny up-to-date Codium on Ubuntu 18.04.4 LTS. The extension page showed "7 downloads", and now "8 downloads" in Codium, and also the "License" link goes to open-vsx.org, which lets me assume it was actually installed from the new store. :+1:

I'd suggest to generalize this topic and call it "Separate Rosetta cleanly from Django Admin".

Why? – Because currently, Rosetta is not even cleanly integrated with the Admin:

• From the user interface, it's not possible to navigate back to the admin (although it seems to be visually integrated)
• Rosetta's templates don't inherit from Django's admin/base.html, which makes it tedious to customize its look and feel

If there were a clean separation it should be easy to allow for a Django setting to use either an integrated Django admin user experience, or a completely independent, stand-alone app appearance and behavior.

That would then potentially obsolete or replace settings like ROSETTA_SHOW_AT_ADMIN_PANEL.

I can confirm this works in the current version (0.9.4).

This issue can probably be closed.

I agree: I would not deprecate or remove the possibility to explicitly specify the full path for an image.

Let me reaffirm, I believe it's a good idea to keep the behavior in sync with the tools the Kubernetes ecosystem provides.

Nice! IIUC there is no command line switch for that, though. You have to enable the feature via .puppet-lint.rc.

Can this feature be made available via a command line switch, too?

Same here. Is there a reason why you change this to small caps?

Why do you start with a lower-case character on these messages (line 86, too), while all the other error messages start with a capital letter?

Doesn't this apply to the entirety of the *_test.go files, too? If we separated the tests out into a dedicated tests folder we'd have this issue solved. But that requires structural changes to the tests. We may want to discuss this after this PR has been merged.

"ConfigMaps" seems to be written with a capital initial letter in all other locations (usage screen, debug output). It might make sense to keep it this way here, too?

It should just work the same way as oc does. Simple as that. There should be no need to reinvent the wheel, no need for a developer used to the OpenShift CLI to learn a new behavior.

I believe, with oc the namespace is like the place where you start your command (similar to pwd in a shell). When you specify the path explicitly this takes precedence. I think that's oc's behavior. Please, let's verify this and keep the behavior in sync between the two CLI's.

The env variables are simply placeholder values with defaults, as documented. If you override or overwrite a configuration file that replaces or excludes the configuration files shipped with the image then your configuration takes over. There is no magic. It should be straight-forward to understand.

Also note that the new images are based on the official Apache and Nginx images, so the directory layout may have changed.

Yes, the environment variables should make it easier to run the container image in a cloud-native setup (e.g. with Kubernetes, but also without). See the README for an explanation of all of them.

Let us know if you find this hard to use, and what your expectations on an easy, yet modern setup are.

Your PR needs to be rebased to be eligible for being merged.

Sorry, no time to improve the tests

This sounds like an arrogant statement. I'm sure you don't mean it that way.

If your changes need tests to be adapted I'm afraid there is no other choice than getting that done, too. If you write tests, if you refactor tests, if you improve tests, that demonstrates professional attitude. If you break tests, that is something that would be unprofessional from our side to accept. We can't do that.

What we can do is offer our support. Let us know where you struggle with aligning the existing tests with your changes. There will be someone taking their time – even if "we don't have it", even when our families would deserve that time more. That's how we people are in the free software community. Ask us! We're happy about your contribution, and we're here to help.

Probably.

(Frankly, I don't care, because I don't use Google Analytics and I would encourage everyone to stop using it, too. But that's a totally different discussion.)

What does Google's documentation say? Are there official patterns of valid ID's? If not let's make it simple for everyone.

However, "flake8" gives warnings on validator.py lines 202 and 205 (lines 174 and 177 in the master branch), which are unrelated to these changes.

This is normal, and happens in all project, recently. The story is that Flake8 got its rules updated to identify code that is hard to understand. This is exactly the case in line 202-204.

I think that deserves fixing, also in this PR, as a side-job. As an act of good citizenship. Simply try to figure out what is the meaning of the code and turn the variable names into something self-explanatory (i.e. long names that actually tell a story).

Is it possible to release a new version in order to get all the fixes from the master branch? Version 1.0 is just broken on python3.6

$ pyclean .
pyclean.py", line 63
    except (IOError, OSError), e:
                             ^
SyntaxError: invalid syntax

Try using the explicit alias py3clean, as I explained in #17. I hope that helps.

The current master mostly contains preparations for an upcoming 2.0.0 release. It's seems broken, actually, for the new --legacy option due to the fact that there were never tests for the Debian scripts that I integrated.

I'll try to work on the next release in the upcoming weeks.

Pyclean is currently just a wrapper around the Debian scripts (as described in and linked to from the README).

Version 1.0.0 installs three direct aliases to the original scripts: pyclean (for Python 2), py3clean (for Python 3), pypyclean (for PyPy3). You may want to try to use them directly to match your Python version.

Note that the plan are to get rid of the heritage (in some ideally backward compatible way) and have just a single implementation. This is what is currently the modern module.

@mhansen Could you turn your suggestion into an acitonable PR, please? This will make it more likely that your feature suggestion comes true.

@bemoody Any plans to finish this PR?

At least, the branch must be rebased and conflicts resolved.

True. This will likely provide a more readable, more usable validation output to everyone.

Can you verify which change would be necessary to the django-analytical code? Ideally, you would create a PR for that.

I think the fallback was to make the tests pass in the pipeline. But that should be obsolete, we do mock the namespace now, don't we?

This PR contains the following updates:

Release Notes

<details> <summary>getsentry/sentry-python</summary>

v0.16.0

Compare Source

• Redis integration: add tags for more commands
• Redis integration: Patch rediscluster package if installed.
• Session tracking: A session is no longer considered crashed if there has been a fatal log message (only unhandled exceptions count).
• Breaking change: Revamping of the tracing API.
• Breaking change: before_send is no longer called for transactions.

</details>

Renovate configuration

:date: Schedule: At any time (no schedule defined).

:vertical_traffic_light: Automerge: Disabled by config. Please merge this manually once you are satisfied.

:recycle: Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.

:no_bell: Ignore: Close this PR and you won't be reminded about this update again.

• [ ] <!-- rebase-check -->If you want to rebase/retry this PR, check this box

This PR has been generated by WhiteSource Renovate. View repository job log here.

We should eventually remove the Piwiki integration as such, one day.

Nice! :confetti_ball: :rocket:

IIUC, the current feature set requires you to handle rotating the backups yourself.

• Whether you compress, encrypt and store to whatever backend, there will always be something like a tarball for every new execution of a backup process. Hence, you have to deal yourself with deleting old copies (and keeping selected ones, e.g. one every week for the last 3 months) to make sure you don't run out of disk space.
• Also, if there are no changes (be it in the database or the media files) there will still be a backup, which will unnecessarily occupy disk space and/or incur additional cost on a storage service.

These problems are solved by backup applications that do deduplicated backups, such as Borg or Restic. The latter is a Go implementation, the former a Python tool.

Would it be realistic to try and integrate those tools in django-dbbackup? Calling them as external binaries would likely be sufficient.

Is the k self-explanatory enough?

@ZuluPro All but the "latest" docs builds ran. Can you trigger also "latest"?

Personally, I would remove the "master" version and use "latest" instead. Everything else seems confusing. What do you think?

@ZuluPro Could you verify the build configuration on Readthedocs? The last (automatic) build was 3 years and 9 months ago. It should build automatically on each change.