Prevent imaginary/empty attributes being retrieved from Analysis

[cortadocodes]

Summary

Prevents imaginary attributes being retrieved from Analysis.

Contents

Minor fixes and improvements

• Closes Analysis attributes are None when they shouldn't be #45

[thclark]

I've just realised why I did this in the first place.
The purpose was to ensure that, once created, users couldn't monkey around with the actual objects, which have a protected UUID attribute.

That way we don't have somebody deciding to override the output_manifest with another Manifest object. Whilst that might not seem a big deal, it'd allow us to keep consistency throughout the process and report what manifest the results will end up in right at the start of the process.

1. I didn't call super().getattr(self, f"_{name}") anywhere, which is why analysis.furry_purry_catwouldreturn Noneinstead of anAttributeError`

2. This still needs a test that the output_manifest is created when the twine has an output_manifest strand, I think that hasn't been fixed yet

[cortadocodes]

@thclark would you like the previous behaviour restored and a call to super().getattr(self, f"_{name}") then?

[thclark]

@thclark would you like the previous behaviour restored and a call to super().getattr(self, f"_{name}") then?

On the one hand we have the philosophy that we should make it as easy as possible for users to do things in sensible ways, but as hard as possible to do things which may have unintended consequences (like pulling the switcharoo on manifests attached to Analysis).

On the other hand, we have our own development efficiency (we're still at an early stage mavericking through this, and if you find it to be easier to debug when the objects are directly attached then we can move through issues quicker) and the general zen of python Simple is better than complex. - may well just lead to fewer bugs exposed to users (like this one!) and less code for us to maintain.

I perhaps lean toward the latter but am torn (and am also suffering from the sunk cost fallacy, because I wrote the code in the first place). Feel free to decide the approach you favour, I'll support you 💯

[cortadocodes]

I'm in favour of the latter too as I think the extra complexity may lead to inadvertent bugs. I'm also thinking that most users won't need to touch the analysis object or anything else if they're using the CLI - is this a correct assumption? Even if they do need/want to, I'm think that the user should be trusted not to mess around with the attributes of objects that have been produced for them via a black box, and if they do change them, it would be reasonable to expect there might be a problem

[thclark]

Looks good to me!

[thclark]

Aha!!