Ticket #4323 (closed defect: fixed)

Opened 6 years ago

Last modified 4 years ago

Pyomo return code reversed

Reported by: gabeh Owned by: wehart
Priority: normal Milestone: Coopr 3.4
Component: pyomo.core Version:
Keywords: Cc:

Description

The return code for the pyomo command line script seems to be reversed (as of revision r5323), i.e, returns 1 when the program executes as expected and zero otherwise. Should this be the other way?

Change History

comment:1 Changed 6 years ago by jdsiiro

This is weirder than it looks. run() can return all manner of things, the least of which is None. run() calls util.run_command(run_pyomo, ...), which in turn calls run_pyomo (usually). However, all manner of things can come back:

  • if you specify, -h, you get None
  • if you specify profiling, you get a list: [ the normal result, None ]
  • other --help-* yield an empty Container()
  • if run_pyomo raises an Exception or SystemExit, then you get 1

This strikes me as a bit of a mess that at the very least needs to be documented, and probably needs to be reconsidered.

Bill?

comment:2 Changed 5 years ago by jwatson

  • Milestone changed from Coopr 3.2 to Coopr 3.x

comment:3 Changed 5 years ago by jdsiiro

Referenced in changeset [6641]:

Updating Pyomo commands to return rational process return codes

  • resolves #4323
  • commit 1 of 3

comment:4 Changed 5 years ago by jdsiiro

Referenced in changeset [6642]:

Updating Pyomo commands to return rational process return codes

  • resolves #4323
  • commit 2 of 3

comment:5 Changed 5 years ago by jdsiiro

Referenced in changeset [6643]:

Updating Pyomo commands to return rational process return codes

  • resolves #4323
  • commit 3 of 3

comment:6 Changed 5 years ago by jdsiiro

  • Status changed from new to closed
  • Resolution set to fixed

Resolved by [6641:6643].

comment:7 Changed 4 years ago by wehart

  • Milestone changed from Coopr 3.x to Coopr 3.4

comment:8 Changed 4 years ago by jdsiiro

Referenced in changeset [8181]:

Fixing tickets #4323 and #4482. We used to support renaming or moving a component simply by assigning it to a new block or by assigning it to a new attribute on the same block (although we tossed a warning).

Attempting this now raises an exception.

Justification for the change in behavior: we implemented the move / rename by internally performing "block.del_component() + block.add_component()". This has the net effect of moving the component to the END of the construction order -- a very bad thing if it is something like a Set where other components were counting on the set to already be constructed (which gave rise to the error reported in #4482)!

comment:9 Changed 4 years ago by jdsiiro

Bogus reference: the above commit should have referenced #4232.

Note: See TracTickets for help on using tickets.