[garrettheel]

This is a very simple change to make properties available when accessing a User via resource.CurrentUser().

For example, it makes the following work:

iam = boto3.resource('iam')
print iam.CurrentUser().arn

I am not sure of how to make the actions available without a large amount of duplication, as these are defined on the User resource. If there's a nice way to do this let me know and I'll update the PR.

As an aside, I also noticed that installing dependencies from requirements.txt installs the latest versions of a few packages from Github which are newer than setup.py expects, causing any setup tasks to fail. It would be good to fix this.

[coveralls]

Coverage remained the same at 98.7% when pulling 1f21c97 on GarrettHeel:develop into ebc0f95 on boto:develop.

[danielgtaylor]

@garrettheel thanks for the pull request! This looks like a very useful change.

I agree that populating this resource with actions is going to require a lot of duplicate effort in the JSON description. One alternative that could work but is a little awkward is to provide a has relationship from CurrentUser to a User instance based on the user_name attribute, which will incur at least one load operation. Something like the following:

    "CurrentUser": {
      "shape": "User",
      "load": {
        "request": {
          "operation": "GetUser"
        },
        "path": "User"
      },
      "has": {
        "User": {
          "resource": {
            "type": "User",
            "identifier": [
              { "target": "Name", "source": "data", "path": "UserName" }
            ]
          }
        }
      },
      "hasMany": {
        ...
      }
    }

Unfortunately not every CurrentUser actually has a .user_name attribute set. @trevorrowe any input on how we can approach this? Is it worth duplicating these actions? I think that would provide the nicest interface, but it's a maintenance burden.

---

As for the requirements.txt vs. setup.py issue, these are different by design. We do development against the latest versions of dependencies (via requirements.txt) but want you to install Boto 3 with a specific set of acceptable dependency versions. If you are going to work on Boto 3, then use pip install -r requirements.txt and pip install -e .. I also highly recommend using virtualenv to isolate these dependencies from the rest of the system. Otherwise as someone using Boto 3 in their own project you can just use pip install . or python setup.py install and it won't mess with the requirements file.

[trevorrowe]

@danielgtaylor We need to do some more looking into this. Some thoughts:

• Adding a load to CurrentUser and then a has association to User based on the user name will produce an association that can return null/nil. There is precedence for this, such as EC2 instance has Subnet.
• Calling GetUser with STS session credentials out-right fails. This forces a requirement on the user to know something about the origin of their credentials.
• While allowed by the resources.json schema, adding actions that rely on a potentially null/nil data member can also generate runtime errors. They can trigger client side validation for missing required prarameters and/or service-side validation for the same.

I'm not suggesting that we should not make these changes, I'm just exploring what the user experience may be. I'm currently more inclined to add the has association to user, but not necessarily duplicating the other associations/actions. At a minimum, users can nil/null check the return from the User association method and stop there if they are using root account credentials.