*system

I use something like this to combat that kind of shenanigan:

clean: clean-build clean-pyc clean-test ## remove all build, test, coverage and Python artifacts

clean-build: ## Remove build artifacts
	rm -fr build/
	rm -fr dist/
	rm -fr .eggs/
	find . -name '*.egg-info' -exec rm -fr {} +
	find . -name '*.egg' -exec rm -f {} +

clean-pyc: ## Remove Python file artifacts
	find . -name '*.pyc' -exec rm -f {} +
	find . -name '*.pyo' -exec rm -f {} +
	find . -name '*~' -exec rm -f {} +
	find . -name '__pycache__' -exec rm -fr {} +

clean-test: ## Remove test and coverage artifacts
	rm -fr .tox/
	rm -f .coverage
	rm -fr htmlcov/
	rm -fr .pytest_cache

dist: clean ## Builds source and wheel package
	python setup.py sdist
	python setup.py bdist_wheel
	ls -l dist

release: dist ## Package and upload a release
	python setup.py sdist upload

very nice

Thanks everyone for tracking down that one!

ours is merely:

clean:
        find . -name \*.pyc -delete
        rm -rf ./dagster/docs/_build
        rm -rf ./dagster/htmlcov/
        rm -rf ./dagster/build/

@max @schrockn Meanwhile the fun continues with this way that configs can leak into logs:

Why does this stacktrace have variable values?

That’s just python afaik

That looks line it is printing out a stack trace from an uncaught exception

Is that a pytest run

It is.

I'm wondering if it has to do with

six.reraise

I would suspect that pytest is doing something clever

To introspect the stack and print things

ooooh good call

For debugging

I didn't even think of that

I suspect these do not appear in any log messages

they sure would if the cconfig isn't correct

Unless you are running pytest in prod

but that's probably a pytest flag that I can easily diable

And capturing stderr

CI is the issue, not prod.

Ah CI logs

yup

Cool. Good luck. Feel free to email me any further issues and I can look async

kk. Thanks!

I’ll be off slack for the rest of the night

👋

0.3.4 released!