global properties from command line has to be set immediately

[AlexeySanko]

Unfortunately, global property values from command line aren't set immediately after project object creation. And we cannot use it for plugins behaviour manage.

[coveralls]

Coverage increased (+0.006%) to 75.012% when pulling 699404b on AlexeySanko:hotfix/command_line_properties into d0f8f80 on pybuilder:master.

[arcivanov]

Could you please rebase on latest master?

[coveralls]

Coverage remained the same at 74.971% when pulling 82555d3 on AlexeySanko:hotfix/command_line_properties into 82acc02 on pybuilder:master.

[AlexeySanko]

Thanks. Rebased.

[arcivanov]

I have to think about this a bit more. This modifies the default behavior and I'm not sure yet what the negative implications of this will be.

[AlexeySanko]

Marked as useless. Closed.

[arcivanov]

Huh?

[coveralls]

Coverage remained the same at 74.971% when pulling 82555d3 on AlexeySanko:hotfix/command_line_properties into 82acc02 on pybuilder:master.

[AlexeySanko]

Ok. Let's repeat step by step what I did when create PR

        self.project = Project(basedir=project_directory)
        self.project_module = self.load_project_module(project_descriptor)
        self.apply_project_attributes()
        self.override_properties(property_overrides)

So in this case we have two statements which will be affected by override_properties movement: load_project_module and apply_project_attributes.

override_properties calls only self.project.set_property and affects only project properties dict. So we need to understand how project properties dict could be change into load_project_module and apply_project_attributes.

load_project_module call imp.load_source and push result to self.project_module. It doesn't affect self.project object.

apply_project_attributes just push attributes self.project_module to self.project attributes. It could affect properties dict if some setter has mirror to property dict.
Let's check:

        self.propagate_property("name")
        self.propagate_property("version")
        self.propagate_property("default_task")
        self.propagate_property("summary")
        self.propagate_property("home_page")
        self.propagate_property("description")
        self.propagate_property("authors")
        self.propagate_property("license")
        self.propagate_property("url")
        self.propagate_property("explicit_namespaces")
        self.propagate_property("requires_python")
        self.propagate_property("obsoletes")

@version.setter - doesn't affect property dict
@requires_python.setter - doesn't affect property dict
@obsoletes.setter - doesn't affect property dict
@explicit_namespaces.setter - doesn't affect property dict

So in this case we have only one way to affect project properties dict into these two steps:

project = Reactor.current_instance().project
project.set_property('install_dependencies_extra_index_url', 'pypi url')

into build.py or any other plugin.
It looks like a hack instead of using tool by expected way.

Currect sequence of getting values into project property dict:
dirty hack -> command line -> inits
If we add possibility to propagate attributes to properties:
dirty hack -> propagation from build.py -> command line -> inits
Why command line replace attributes from build.py?

From logical point of view sequence of applying could be equal to sequence of calls.
command line -> import stage (propogation and hacks) -> init

Cons:
We will affect dirty hack with Reactor.current_instance().project usage - system will not replace dirty hack properties with command line properties

Does anybody really use this logic with replacement dirty hack properties with command line properties? Really???? Simpler contribute PyB than find this possibility.

Pros:
We will get properties from command line as first step. And could manage ANY building step. And we can use existing finctionality instead of adding any additional task.